Plasma Bug Workflow BOF

[Mark]

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.

>
> While we all would like to have the complete triaging process taken
> away from the developers we currently are quite far from that and even
> if it is not something a dev. likes to do I think with a common effort
> it should be doable. What saddens me is that I hear from plasma
> developers that they don't have time and are not willing to ever
> actually triage bugs, and that is exactly the attitude that lead us to
> the situation with close to 2000 (not 1400, the figure was much, much
> worse) open and untriaged reports. And I don't even talk about the
> wishes which is a completely different matter.
>
> What needs to be understood is that all code can have bugs, that is
> only natural and nobody will deny that. But that also means that we
> should thrive to make the code better, and IMHO to some extend a
> developer should feel responsible for the code s/he commits and also
> take care of the bugs that are found.
>
> While I understand that nobody likes pressure it should also be
> understood the perception from the other side: developers not even
> looking at bugs in their own code are perceived as arrogant and
> uncooperative. With the current situation the politics of putting the
> head in the ground or just walking away with the "I don't have time"
> wave is not going to help, so efforts need to be done on all sides.
>
> 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)
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

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 actually
think we should hold a plasma bug sprint to clean up all bugs that are
opened before the KDE 4 days. When i look at those bugs i simply don't
know what to do with them. A few days ago i did do a bit of bug
triaging (as you have seen :p) but even then i'm barely making a dent
in the total bug count. I triaged about 30 or so, but closed just a
few. That's a bit demotivating..