Managing Bugs in KDE (Re: When to set VERIFIED in BugZilla?)

[Carlos Leonhard Woelz]

OK: now we are going for a virtual discussion. I shoud avoid discussing
things I won't implement. The KDE style of discussing stuff is to replace
"we should" with "I will". That said, there are people on this list who
told me in private mail they want to be bug maintainers. So here is some
guidance on the subject.

On Fri, 12 Mar 2004 04:15:53 -0800 (PST), "Marc Heyvaert"
<marc_heyvaert at yahoo.com> said:
> Hello all
> 
> Just jumping in because bugs is one area where I want
> to become active...I may have missed some of the msg
> that where posted earlier.
> 
> Could someone explain me what the life cycle of a KDE
> bug is then,
>
> Especially how it eventually disappears. I mean, when
> it is resolved, fixed or whatever, it has to be
> closed, hasn't it?

Cornelius answered that in another mail.

But I just want to add areality check: there is much to do before we
start requiring the VERIFIED => CLOSED cycle.

Current state: there isn't even sufficient manpower to handle the bugs we
receive even without "QA" team confirmation. Note that this "QA" team
that confirms bugs is not proper (strict sense) QA.

Proof: see the chart with the evolution of unconfirmed bugs:

http://bugs.kde.org/reports.cgi?product=-All-&output=show_chart&datasets=NEW%3A&datasets=ASSIGNED%3A&datasets=REOPENED%3A&datasets=UNCONFIRMED%3A

The objective here is to reduce the amount of time developers need to
spend to handle bugs. The chart shows the rise in the number of
unconfirmed bugs. Checking if these uncunfirmed bugs really exist, and
providing better information on how to reproduce them already improves a
lot the current situation. Also, checking if old "confirmed"(new) bugs,
still apply helps making the database clean. More about that here:

http://quality.kde.org/develop/howto/howtobugs.php

If we gather people to help in that area, we can reach step one:

Step one: bugs are well maintained, there are no invalid bugs in the
list, there is a list of critical bugs open, according to guidelines
agreed by the KDE developers.

If we have even more resources, we can get to step two:

Step two: bugs are well maintained, there are no invalid bugs in the
list, there is a list of critical bugs open, according to guidelines
agreed by the KDE developers, and there a confirmation for closed bugs by
the QA team. (RESOLVED => VERIFIED => CLOSED)

I don't think the next step is desirable:

Step Three: Strict QA, the formal (bureaucratic) process: not sure if
possible only with volunteer work. May be possible for some areas inside
KDE, like kioslaves, or very specialized programs. May be possible if
someone is sponsoring this and paying developers to design the program ,
apply it and fix the issues to guarantee the conformance. I suspect the
informal process we currently have is much more resource efficient.

> > >> Clearly bugs reported against HEAD should be
> > treated differently -- so
> > >>  that is another issue that bugs reported against
> > HEAD should be 
> > >> identified as such (on BugZilla) by the reporter.
> > > 
> > > I think that the current behavior is to backport
> > only to the last stable
> > >  branch. Otherwise, one would have to spend
> > limited man power to keep 
> > > old branches up to date.
> 
> For me a bug is a bug, so should be reported. If I
> were a developer, I would even put *all* bugs in the
> database, even those that I discovered myself, because
> it is an easy way to track all your work and to
> organise the info that is needed for the problem at
> hand. It is extra documentation in a way. But not all
> developers seem to think this.
> 
> It is true that most users report bugs that appear in
> a stable branch, so backporting should be done. But
> vertainly not further than the latest branch, if a
                                 ^^^^^^^^^^^^^^
> user goes through the trouble of updating his packages
> it will be the latest stable release anyway. 

If you mean the latest *stable* branch, yes, we all agree (that was never
in doubt) that bugs should be backported to the latest stable branch. If
you become a bug manager, you will quickly learn that sometimes it is
easy, sometimes it is hard to backport the bugs to the stable branch. You
as a bug manager can even backport and test yourself the changes, when
the fix is simple.

Cheers,

Carlos Woelz
-- 
  Carlos Leonhard Woelz
  carloswoelz at imap-mail.com

-- 
http://www.fastmail.fm - Faster than the air-speed velocity of an
                          unladen european swallow