[rfc] Should we "block" bugreports for the latest stable releases of KDE apps?

[Robert Knight]

It depends on the nature of the bug report.  Sometimes bugs are
reported for very old versions which are still valid for the most
current version.  This obviously includes wishlist items but also
sometimes bugs which were not fixed in an old version for
architectural reasons.

In the past few months I have ticked off a few reports which were
originally filed against KDE 2.x or early 3.x releases.

We can advise people that bugs in old versions are unlikely to be
fixed but I would advise against a wholesale ban on such reports, not
least because we don't want to discourage people from reporting real
problems in the first place.  KDE's bugzilla is not the prettiest
thing in the world but filing reports is relatively quick and easy for
those who have the inclination to do so.

> That's a nice theory, but unfortunately it's probably just that. We already
> can't keep up with the incoming bugreports

Again, that depends on the program and the time that the maintainer
has available.  If there is a single person actively maintaining a
program for a few hours a week then up to ~300 unresolved bugs is I
think managable.

Regards,
Robert.

On 25/04/2008, Krzysztof Lichota <krzysiek at lichota.net> wrote:
> 2008/4/25, Lubos Lunak <l.lunak at suse.cz>:
>
> > On Friday 25 of April 2008, Krzysztof Lichota wrote:
>
> >  > IMO bugs for older KDE version should be accepted, marked as
>  >  > "Untriaged for current version" or something similar, and then someone
>  >  > with latest KDE version can verify if this bug still happens.
>  >
>  >  That's a nice theory, but unfortunately it's probably just that. We already
>  >  can't keep up with the incoming bugreports. Even if we allowed stuff from
>  >  KDE3.5.5 or older (and that's a year and half old), the first reaction of
>  >  most developers is going to be 'Can you reproduce with the latest version?".
>  >  And the reporter says that they don't know, and the developer shelves the
>  >  bugreport for somewhen when they'll have time to check (=indefinitely).
>  >  Where's the gain in that?
>
>
> Well, it depends if you want to have as little bug reports as
>  possible, or you want the bugs to be really fixed.
>
>  And please notice that the process I have described involves some
>  other people than developers - bug triagers. I think it is waste of
>  precious developers time if developers have to triage bugs. This can
>  be done by people who are not developers, it is enough if they are
>  "power users", who know a bit more about KDE. There should be team of
>  bug triagers for KDE who are the first line of bug reports - AFAIK it
>  is not the case now with KDE bug reporting scheme.
>
>  The bug reporting process IMO should be like that:
>  1. Bug reported -> untriaged state. Developers do not see these bugs.
>  2. Bug triager checks if this bug is duplicate, verifies the bug
>  existence in latest KDE and assigns it to proper KDE module (sometimes
>  reporters do not have enough knowledge to correctly assign bugs).
>  3. Now the developer should take a look at this bug, when it is really
>  a new, currently existing bug.
>
>  Regards
>
>  Krzysztof Lichota
>
>  PS. I have stopped submitting bugs for KDE a long time ago as I cannot
>  keep up with latest  KDE releases. And it is not like I have not
>  reported any bugs in the past, see:
>  http://bugs.kde.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&bugidtype=include&bug_id=&votes=&emailassigned_to1=1&emailtype1=substring&email1=&emailreporter2=1&emailtype2=substring&email2=lichota&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&order=Reuse+same+sort+as+last+time&cmdtype=doit
>