关于 bugs.kde.org 的一些想法

adaptee | 2011/10/01

有感于最近围绕bugs.kde.org(下文简称BKO)的一些讨论,写一些自己对于BKO的想法。

客观事实:KDE 的开发者账户数量[1]目前为2513,而 KDE的用户数量应该有百万级别。这个数量对比很重要,所以读下文时请多回想一下。

BKO目前的问题:report 数量过多(23000+),且每周都以400+左右的数量增加(这里没考虑同时关掉的report)

用户对于BKO的抱怨:report 长期得不到解决或者得不到开发者的回应,甚至一两年后仍是 0 comemnt 和 ‘UNCONFIRMED’ 状态。用户觉得自己被开发者忽略了。

开发者对于BKO的抱怨:没有价值的report太多了, BKO没有发挥预期的帮助开发者跟踪问题和安排开发计划的作用,反而成了干扰开发者的噪声, 延缓了开发进度。

我认为两方面的抱怨都非常有道理,不存在谁对谁错的问题。问题的根源在于BKO:BKO上存在太多没有价值的report。这里的没有价值有几种表现形式:

1). 重复的 report: 这个没什么好解释的 2). 语焉不详的 report: 问题表述的含糊不清,也缺乏具体清晰的重现步骤,需要开发者问各种问题 3). 价值很小的crash report : 无法高概率的重现,或是backtrace里没有debug sybmols 4). 错误的报告对象;比如大多数shortcut相关的问题都应该报告给kdelibs,而不是具体的某个KDE程序 5). 不是 bug 的 report: 个人配置问题,或是发行版的问题

我目前只参与了konsole的开发,就列举下konsole的数字来说明这些没有价值的report多到了什么程度。

konsole目前有260个report(绝大部分我认为都是有价值的);过去的90天内,343个针对konsole的report被关闭,这其中大概有50~70个report是有价值并得到修复的,其余的都是没有价值的report。粗略估算的结果是 50%的report都是无益的噪声。有兴趣的读者还可以看一下dolphin目前的174 个 crash report[2] 。情况糟糕的一塌糊涂,我估计里面有价值的不超过50个。

那么该为这些无价值report负责任的是谁?我要给出一个刺耳的看法了:BKO,还有用户。

BKO应该更激进的阻止用户提交无价值的report,譬如在当前版本为4.7.1的情况下,就不允许提交针对4.6.x的report,因为这样的report几乎肯定是重复的,或者已经在最新版本里解决了;另一方面,BKO则应强制用户提供更多的信息,譬如重要的Qt版本,标题和描述不得少于多少字(我见过两个令人吐血的report标题,一个叫samba,一个叫default)。用户应该更谨慎的提交report,先通过发行版的支持渠道来寻求帮助和解答,有足够把握后再考虑BKO.

在理想世界中,清理无用的report是KDE开发者工作的一部分。但是现实世界中这几乎是不可能的任务:清理BKO的成本过于昂贵了,它会吞噬掉开发者大部分原本能用于开发工作的时间。用户提交一个report大概要花掉5分钟的时间,而开发者分析、确认和关闭一个无价值report的平均时间要远多于5分钟。请再回想一下开发者和用户数量的对比,以及我前面估计的无价值report的比率。konsole 最近关闭的这300+的report我大部分都有参与,我个人的感受是花在关闭无价值report上的时间要比写代码的时间多很多,更不要提乐趣上的天壤之别了。

再强调一遍这些无价值的report给开发者、用户带来的负面影响:清理会吞噬开发者大部分的时间; 不清理则成为了BKO里的噪声,而且严重影响开发者的情绪和用户对产品的信心。想像一个只有2、3个人的小团队面临BKO上 600+ 的report时该有多沮丧(我指得是几个月前的konsole),想像用户面对一个report 2000+ 且没人清理report的产品(没错,我指的是目前的plasma)时是否心存疑虑、信心不足。每增加一个无价值的report,就意味着那些有价值的report的解决时间被延后了。

基于BKO的现状,如果真的有提交report的打算,我强烈建议考虑如下事项:

0). KDE版本是否最新? 如果用的是Ubutnu/Fedora/OpenSuSE这样的周期性发行版,基本上都是旧版本,发现的问题基本上都已经被报告过或是解决了, 强烈建议在此步停止。 1). 首先排除个人配置导致问题的可能性 2). 优先从发行版的支持渠道寻求帮助,最好的结果是发行版的开发者确认问题的存在并由他们向BKO提交report 3). 提交前请务必多搜索几遍寻找重复的report,这也许令你觉得麻烦,但是这是在帮助KDE。 4). 标题和内容请务必写的清晰和详细。”xxx crash” 和 “xxx doesn’t work” 这样的标题只比”default”、”samba”略好,千万别这么写。务必写上清晰的重现步骤,即使问题看起来如此简单明显而不需要写明重现步骤 5). 最好附上Qt版本 6). 在comment里讽刺开发者反应迟钝绝对不是个好主意。开发者巴不得解决所有的问题,但是做不到。讽刺只会让开发者感到沮丧和恼火,并在自己的开发计划里降低这个report的优先级

[1] http://websvn.kde.org/trunk/kde-common/accounts?view=markup [2] https://bugs.kde.org/buglist.cgi?product=dolphin&component=general&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=crash

    11 FEEDBACKS

    1. 关于 0) 先报给发行版更好。发行版的处理bug的人貌似更负责一点……能够减轻一些KDE的负担。

    2. 悄悄地说,由于我的英文水平问题,每次报Bug都得花15分钟以上推敲字句,所以想不谨慎都不行…… -_-||

      作为一个没啥本事的用户,我有时也很为难。有的问题明显影响到了日常应用,然而很多时候用户并不知道问题可能出在哪里,如何才能给开发者有用的信息。也许装Debug模块,用KDE桌面提供的崩溃回报会好一些,但不是所有的软件都有发行版打的现成的debug包,自己从官网上抓的话成本也确实很高。 看来最好的办法还是先报给发行版(为啥让我想起了人民代表大会……)。

      关于版本问题……很多时候新版本出来了,但问题依旧很多,不如旧版本的最后一版稳定。即使新版本里的东西修复了,有的用户仍然愿意用旧版本。恐怕这是Bugs不关闭旧版本Bug回报的主要原因。

    3. tmk

      个人觉得也有kde正式版发布前的测试很有问题。 每次新特性的出现,几乎不可避免的带来新的bug,当然,这可以理解。但是,让人费解的是,这些新bug有很多是非差显而易见的,或者只要正常体验一下新版程序,就能很容易发现的bug,然而,这些新bug可能又是严重影响用户体验的——开发者如果在发布之前无法修复,那么应该暂时禁用带来bug的新特性。 事实是,这种带有严重bug的新特性仍然默认开启了,这种带有严重缺陷的软件一次次在正式版中发布了。 从kde4的极不稳定中走过来,并且非常期待稳定的的用户发现,一次次新正式版本的发布,并没有给他们想要的稳定性,反而一次次带来新的问题。这种情况下,用户感到愤怒和不满是可以理解的。所以,才有了关于foldview 那个重命名bug的激烈争吵。

    4. @tmk 开发者发现不了的bug是非常正常的…… 比如那个文件夹视图,老实说我不用,并且……我进行改名操作也非常少。

      我开发fcitx的时候,只有自己用的拼音bug少,码表乃至双拼有bug持续多个版本发现不了都是正常的……老实说所以我很需要有直接用snapshot的人帮助测试。功能和bug数量是成正比的,尤其是这种GUI-based的程序,很难完成unittest来测试所有的操作都是正常的。以前fcitx的bug堆到一两百,削减到70个之后,剩下的不知怎么办几十个的全部粗暴关闭,模板式回复一句请尝试新版本。

      或者某天遇见一个不能reproduce的bug,那直接就是扔一边不管的。linux下面可能的库的combination太多了,发布前也不能测试过所有的发行版保证全部都没有问题。而且老实说目前我也不了解某些开发团队的大小,人数出乎意料的少也是很可能的。

    5. Alisha

      在TechBase上有一篇說明如何建立有用的當機report的文章,對想提交report的人很值得一看。 http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports_(zh_CN)

    6. @csslayer

      同意csslayer 关于 0) 的看法. 发行版打包的时候不一定选择最新版本的源码,这种情况下发行版的社区也有一定的义务来帮助维护他们所选择的版本,并且在收到bug report之后,如果确认bug在上游已经修复而发行版二进制包中仍未跟进,那么包维护者应该考虑是否更新包的版本或者手动打上修复bug的补丁重新打包.发行版的社区应该做到分流一部分”过时”的bug,并且帮助筛选出有价值的bug转交给上游,不然不仅没有给用户带来最好的体验,还会因为旧版本的bug给开发者带来更多的负担,这样的发行版存在的意义就大打折扣了.

    7. Franklin

      有些專案(如 Mageia) 有一種角色叫做 Triage,也就是負責整理回報到 BTS (Bug Tracking System, 以 Mageia 為例是 Bugzilla),找出重複的,把有用的資訊指定給開發者。算是開發者與使用者間的溝通橋樑。不過這類角色很吃力,也需要很大的熱情。

      個人倒是不十分同意在 4.7.1 發布後就禁止回報 4.6.x 的 bug。因為許多 distro (對,如 Mageia) 對 KDE 的更新沒那麼快,只有在 cauldron (類似 debian 的 unstable) 版本上才有最新的 KDE,但我使用的辦公室電腦需要的是穩定,一直更新 cauldron 常常下場就是變成一個無法使用的系統… 我覺得需要的還是一群熱心人士幫忙整理 BKO 上的 issue。

    8. tmk

      @Franklin 同意。认为新版kde发布后,旧版的bug在此之前一定已经报告过了或者已经在新版解决了是不恰当的。 @csslayer 有很多bug开发者的确发现不了。但是有一些如果开发者在发布之前认真测试,在他拥有的环境下,避免严重的bug仍然是可能的。 比如,akonadi的那个imap资源,在系统休眠之后恢复或开机不自动联网,它的资源同步会一直停留在离线状态,即使网络恢复正常。这种bug严重影响了使用(如kmail使用该资源,可能会错过重要邮件),如果开发者有心,那么在已有环境下模拟各种不稳定网络或网络中断进行比较极端的测试仍是可能的。总之,如果开发者每次在发布前前慎重对待新增特性,充分利用已有环境进行测试,一些严重影响使用的bug是可以减少的,而且可以获得用户的信任。 我始终认为,一个自由软件发布之后,它的意义不仅仅是开发者的兴趣和分享,只要软件还在维护,软件的稳定性应该是对用户最基本的责任。

    9. stecue

      @tmk 自由软件分发协议总是有一段: No Warranty. :)所以开发成什么样完全看开发者的态度,呵呵。firefox, thunderbird, fcitx这些俺都是信任开发者的,嘿嘿。

    10. tmk

      @stecue No Warranty之是区别于商业软件责任担保的免责申明,但是如果开发者对于软件发布倾向于那种态度的话,那就危险了……

    11. BUGZILLA多好,不断骚扰维护人员

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Note: Commenter is allowed to use '@User+blank' to automatically notify your reply to other commenter. e.g, if ABC is one of commenter of this post, then write '@ABC '(exclude ') will automatically send your comment to ABC. Using '@all ' to notify all previous commenters. Be sure that the value of User should exactly match with commenter's name (case sensitive).