Plasma Bug Workflow BOF

[David Edmundson]

On Fri, Jun 22, 2012 at 3:49 PM, Myriam Schweingruber <myriam at kde.org> wrote:
> 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".

Plasma (now) encompasses everything inside KDE-Workspaces, it's the
"plasma-workspace".
So when people say Plasma, they're not always talking about the part
in bugzilla titled "plasma", which relates only to the "plasma-shell".
It's somewhat confusing right now.

This very recent wiki page might help:
http://community.kde.org/Plasma/Terminology

Dave

>
> 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