/

[chuxinyuan]

[chuxinyuan]

[BLumia]

研发和测试都有在统计相关的信息的。不过解决速度也取决于问题的优先级。目前从研发角度而言，优先处理的都是和 v23 release 挂钩的高优先问题。

如果你也想统计的话，关注 developer-center 仓库的 issue 面板就可以了。

[c61292558]

既然很容易解决，为什么你不提交一下pr代码？

[BLumia]

这样仅仅解决了一个问题，版本不停的在更新...

有 PR 建议提。合入进去的提交除非有特殊原因，否则是不会回退的。

[c61292558]

先功能后ui，先把功能做好或者bug修好再调UI的道理你不懂？你提了pr难道后面就不能调UI了吗？

[chuxinyuan]

[c61292558]

响应速度快并不等于系统能用，cutefish连deepin目前的可用性都做不到

[BLumia]

开发人员是和稀泥水平真的一流

主要这个页面不是我（或者说我们研发人员）在维护，所以我们也更新不了。以及我们研发目前都在修 v23 的各种问题来确保 v23 能顺利发出去。。。这个页面的事情，节后我再催一下运营那边吧。

这个页面都多年不更新了，不知道是谁在负责。

@myml 之前我有过一个 proposal，希望我们自己的应用去适配 AppStream spec，然后这些页面可以直接适应 AppStream 的信息来生成。这样可以保证：

1. 可以自动化更新这些信息
2. 同时确保这些信息可翻译
3. 确保支持 AppStream 的其它位置（或者说其原本的预期场景，即应用商店）也可以使用相同的信息做出呈现

考虑到 v23 发布之前会持续很忙，这个要不我在 v23 release 后推进一下？或者由其他人员推进下？

[BLumia]

这个评价给到深度员工

抱歉，为了避免混淆，作为澄清：我也确实是员工，只是非工作时间还是会以普通贡献者的身份参与社区讨论（这本身不是工作范围内要求的）。当然我也确实认为我们在这方面做的不够好。

每个问题放在数据库里，逐个解决，不可能漏掉的。

我们确实有在处理问题，但其实观察一段时间就会发现，只要存在新特性的迭代开发，那么问题数量就不会是仅仅单纯的减少。这有点类似一边放水一边接水，水就不会有那么容易放完的情况。同时，也是因为近似的原因，才会有优先级的标注（因为短期内确实是修不完的）。

i.e. 我们知道存在很多问题，只是目前在优先处理的全是被认为 RC/正式版 必解的问题。

我作为一个普通“冰箱”用户，没时间精力，也没能力下场“制冷”，但是评价“冰箱”制冷效果并无不妥。

认同这一点，但我觉得还是存在一些差异。你是冰箱的消费者、冰箱厂商的客户，而对于 deepin 而言，则是 deepin 社区的参与者而非消费者。角度是有细微的差别的。

回归正题的讨论就发到另一个回复下吧 :)

[c61292558]

这个评价给到深度员工，没说你啊，我说的是我手动 Mark as the best answer 的那位。其实我对你还是比较认可的，比较积极主动的和用户沟通，耐心回复用户的每个问题，你比他们更像深度员工。

---

但是深度的员工也没欠你的

---

我作为一个普通“冰箱”用户，没时间精力，也没能力下场“制冷”，但是评价“冰箱”制冷效果并无不妥。Deepin OS 代表着国产操作系统的希望，绝对不能这样拉跨，爱之深，责之切。

---

请问你为项目捐款了吗？也不见得你有多“爱”，更不要说责之切了
而且你站在制高点上指指点点的，像个圣母biao一样。“混日子等死的节奏”是你说的，就你那语气，完全就是在羞辱唾骂，而不是客观“评价”

[c61292558]

我作为一个普通“冰箱”用户，没时间精力，也没能力下场“制冷”，但是评价“冰箱”制冷效果并无不妥。Deepin OS 代表着国产操作系统的希望，绝对不能这样拉跨，爱之深，责之切。

请问你为项目捐款了吗？也不见得你有多“爱”，更不要说责之切了

你认为对深度的爱就只剩下捐款了吗？你先把你说话的逻辑理清楚再发表你的高见，这个和写程序是一样的。

所以站在制高点上制裁别人就是你所谓的‘爱’，可笑，捐款是普通人最容易的支持了，难不成要求你提个PR？pr你也提不了，代码你都不提交，爱个mao？你辱骂两下谁不会？嘴炮谁不会？把嘴炮说成爱的，是多么无耻。

[c61292558]

这个评价给到深度员工，没说你啊，我说的是我手动 Mark as the best answer 的那位。其实我对你还是比较认可的，比较积极主动的和用户沟通，耐心回复用户的每个问题，你比他们更像深度员工。

但是深度的员工也没欠你的

你认为我是因为抱着深度欠我的心态才来这里提意见和建议的吗？

那就请你以一个平等尊重的语气发言！

[c61292558]

“和稀泥”“混吃等死的节奏”是在你提的issue里面出现的，但凡是个正常人都看得出你是什么教养
而且对待什么人我就应该给什么样的态度，要是对待一只疯狗没必要客气。

---

但凡你多写两行代码都不至于是提issue里的这种语气

---

别人怎么提issue，你怎么提issue，素质对比一目了然。

[BLumia]

看你还是蛮关注 deepin 社区的，但又不是特别的关注。如果你有更多兴趣的话，我建议你加入我们的 Telegram 或 Matrix 聊天室，有一些问题的讨论上会更方便，甚至包括催一些问题的进度（（

其实你的评论颇有一些纸上谈兵的意思在里面。我在这里统一答复下你几个新回复里提到的点吧。

我没有看到你们给每个 issue 分类以及设置优先级的标签啊？

我们有在使用一个单独的平台来聚合统计 developer-center 的 issue 状态，并根据优先级处理问题。其中由 QA 提出的问题，优先级直接体现在了标题上。由非 QA 提出的则需要 triage 后才会优先在聚合平台内标注，然后视情况同步到 Issue 标签上。当然这个平台目前只有 UnionTech 员工看得到。

先把历史版本的问题都解决了再开发下一个版本不好吗？

“都”解决是不见得现实的，你可以瞅一眼 developer-center 目前有多少 Issue。如果你真的对软件开发生命周期的实践操作感兴趣的话，建议参阅一些软件工程相关的书籍或者资料。当然虽说我这么回答是站在 DDE 整个项目视角而言而不是应用项目视角而言的，但这个事情本身也可以适用到应用项目上。

但是很容易解决，顺手就能解决的

我们非常欢迎 PR，并且只要 PR 质量过关没问题的话，无论项目是否是开源社区中心维护，我本人都承诺我会帮你推进 PR 的合入。

所以我首先提了一个 关于 deepin-music UI 美化建议 结果一直没有人响应。

https://github.com/orgs/linuxdeepin/discussions/5789#discussioncomment-7235772 我看 PM 响应过呀，怎么叫没有人响应呢？

我之前也说过，UI 建议这种内容是见仁见智的，并不是说有人提就一定会改。就其它项目（比如启动器和 dock）的情况而言，即便我们目前没有那么频繁的调整 UI，每次调整仍然是调整满足了一波人的需求，但也使另一波原本满意的人不再满意了。所以尤其是这类很主观的反馈，我们能做的只能是先记录，然后由设计人员决定到底改不改，以及什么时候改。

自从 Gnome 更新到 45 后我就压根没有在 Manjaro 系统上安装成功过深度音乐。

这里其实涉及到三点问题：

1. DDE 系列应用是首要确保 DDE 环境下的使用的。GNOME 或者别的环境 QA 是没主动测过的。
2. 我们不维护 Manjaro 的软件包。由于 Manjaro 主动故意延迟一段时间更新软件包，所以很多 dtk 与 DDE 的问题都是我们修过但是 Manjaro 仍然存在的。这点上我们建议尝试在 Arch 上看看能否复现。
3. deepin 第一方的 QA 只确保 deepin 发行版（以及 UOS）上的场景。不过我们其实有向其它发行版移植的 SIG（我也在对应的 SIG 里面），但移植 SIG 也只能覆盖到此 SIG 成员们自己所用的发行版和桌面环境。

所以这个问题上，我的建议是，先尝试 Arch 上是否也存在，是的话，开 issue。

[BLumia]

不要期望用户做更多“制冷”的工作。

这个放心，没有这种期望，只是说实际软件工程的实践比你想象的复杂 😂

issue 的个数是有限的，实在无法解决的不解决，目标是让 issue 的个数变成 0

这个目标没你想象的那么容易，真的 :)

我就不明白，干嘛着急发行新版本

我这么说你可能会更容易理解：这其实 不完全是 一个 技术 问题。这里的版本发布时间有一些其它的因素掺在里面，由于涉及到一些暂时不可公开的商业版本相关的信息，所以我就不在此详细阐述了。

我说的是方法论问题，三个维度，... 我是说易在难之前，这个你应该不会有意见吧？不要一上来就你行你上啊这样的思维模式

这点我没意见，但于此同时你也就不能做出 虽然优先级不高，但是很容易解决，顺手就能解决 的评价了。如果你认为是顺手就可以解决，那么我们非常建议你顺手解决。如果你不打算的话，你认为的顺手不见得是别人认为的顺手，因此不能做出这样的评价。

在我看来这个只能叫响，而没有应。如果你说响应了，那也算吧！我更想表达的意思是把这个问题给解决掉。

“响应” 这个词本身就只表示有答复而不能表示解决的。以及，和之前提到过的一样，这类很主观的问题往往不会看到一两个反馈就做出调整。

还拿之前提到的 dock 举例，v23 beta3 与 v23 rc 内测版的 dock 变化巨大，就已经有听到“大好评”和“无法接受”的两种声音了，两者无论好坏的评价我认为都是主观评价，UI 与 UX 本身注定就不是一套方案能满足所有人的，而 DDE 与 deepin 应用的 UI 与 UX 则是收到反馈后，由 PM 与设计人员讨论后最终决定是否做出调整。

当然官网图片陈旧是另一回事，我目前能做的大概只是再催一下 🤣

审美问题确实存在仁者见仁问题，不像真理问题，但是美女和丑女的标准也还是有章可循的

不不不，“美女和丑女”的美丑就是由审美决定的，比如有人喜欢大胸有人喜欢平胸，何为标准？

Manjaro Gnome 环境能否运行你们的软件，这个确实和你们没太多关系。但是格局有大，要有大胸怀大气魄，要有深度出品必输精品的 geek 精神，如果深度开发的软件能在更多的 Linux 发行版上运行，深度的知名度和美誉度也会加分不少。

完全认同。这也是我们组建移植相关的 SIG 的初衷，和不同发行版的打包人员一同解决各类兼容问题。只是这个过程必然会是持续的。

---

回到主题，健全更新机制问题。

其实即便没这个帖子，我也已经在推进各个项目逐步提供 AppStream 支持了（例如公开的社区周分享会以及内部的一些讨论我都会提，并且目前也是有一些进展的），只是这个推进过程出于各种原因有些缓慢。长远而言，我计划按 https://github.com/orgs/linuxdeepin/discussions/8364#discussioncomment-9294936 这里提到的方案进行推进，而目前则需要我主动解决另一些（会阻塞推进的）问题，例如 AppStream 相关工具的新版本打包与进仓等，提供一些自动化工具，然后可能也需要做一些宣讲来让各个项目组可以更轻松的去提供支持。

当然，短期方案还是让运营人员去直接更新图片就是了 😂