Plasma Bug Workflow BOF

[Myriam Schweingruber]

Hi Mark,

On Fri, Jun 22, 2012 at 4:26 PM, Mark <markg85 at gmail.com> wrote:
> On Fri, Jun 22, 2012 at 3:11 PM, Myriam Schweingruber <myriam at kde.org> wrote:
>> Hi Thijs,
>>
>> On Fri, Jun 22, 2012 at 10:22 AM, Thijs Heus
>> <thijs22nospam at googlemail.com> wrote:
>>> Hi Martin,
>>>
>> ...
>>> My personal opinion, which counts for nothing: BKO can only work with less
>>> than 50 bugs or so per component. So be rigurous. BKO can only work as a
>>> developers tool if the developers want to use it, if they can have
>>> developers discussions within the report (like KWin does, or telepathy). The
>>> difference is that Plasma got almost 1400 bug reports in the past half year
>>> more than 10% of all of KDE, not even counting the bugs that ended up being
>>> redirected to nepomuk, kwin, solid, etc. Currently there are ~800 bugs open,
>>> my guess would be about 500 real bugs in a current version. That makes a bug
>>> overturn time of only 2 or 3 months.
>>> These are impressive numbers, and they show that Plasma is doing OK in
>>> beating the bugs, even though plasma may not yet be doing OK in beating BKO.
>>> So should we really keep minor bugs that will never be fixed unless as
>>> colleteral damage open? Crashes of over a year old, without any duplicate
>>> since? I am not saying that these are no bugs, just that they are not
>>> helpful reports (anymore), and thus pollute the database. For a highly
>>> visible project like plasma, the amount of eyeballs is so high that an
>>> accidentally closed bug will be reported again. Currently, this is working
>>> against us, but we could make it work a bit more in our favor if we want
>>> to.
>>
>> I agree with most of your points here, but what we really should avoid
>> is closing reports without any comments, that should never happen, and
>> sadly it did in the past and that is something that only causes anger
>> from the bug reporters
>>
>> As for the current bugs it is crucial that all incoming reports are
>> triaged ASAP. We can hold a bugsprint to tackle the remaining
>> duplicates and close old ones, but what counts are the bugs that are
>> reported now. If we continue to ignore those the b.k.o situation will
>> not improve.
>>
>> I have in mind an initiative similar to what Ubuntu does with their
>> "Five a day": https://wiki.ubuntu.com/5-A-Day
>
> Five bugs a day is a dayjob :p Considering that one bug can often take
> a full day (in time) from start to finish. Now i'm only talking about
> real bugs that are indeed confimed, hunted down to the part that
> causes the bug and making a fix for it. Placing it in reviewboard
> takes a few days as well.

Wait, you misunderstood: I talk about triaging, not about fixing :)
Triaging one bug is a matter of minutes most of the time. Example: an
incoming crash report: check if there is a backtrace, identify the
FunctionCall that is most likely to cause the crash, search for
duplicates, try to reproduce if no dupes are around. Since 90% of the
bug reports at least are probably already reported this only rarely
involves reproducing

...
> The thing i hate when i look in bugzilla in the plasma bugs is the
> amount of ancient old bugs even before the KDE 4 time. I

Erm, we had Plasma in KDE3? Also, when did you last have a look at
Bugzilla for Plasma bugs? Your comment makes me think of "not since a
long time".

Regards, Myriam
-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)