On Fri, Apr 27, 2012 at 10:09, Per Jessen wrote:

This thread is from -factory, but it applies to the project overall:

Christian Boltz wrote:

...

...

...

Bugzilla is overpowered, I have issues without attention for years.

In theory, yes, all issues probably should go via bugzilla. In practice, I know we don't work like that and that's why I said its worth discussing. We need to think about how we want to work.

What about "force developers to read bugzilla mails/work on their buglist regularly"? ;-)

Bugreports getting dusty is a real problem, and I'd love to present a nostrum how to fix that if I had one.

I second that.  The worst problem I have here is when someone picks up an ancient (>6 months old) bugreport and asks me for diagnostics , "could you try <something>?" or "please try with latest version". If I'm lucky, I'll remember which system, which configuration and which softeware I was testing, but more often than not, the system has gone into production, has been reconfigured for something else or is being used by somebodyelse.

I'm considering simply closing my old reports as "CANTFIX" due to "NORESOURCES".

This isn't unique to openSUSE. Most project Bugzillas are overwhelmed. Small number of people trying to deal with a large workload. Once the bug reporting system is overwhelmed, it's hard to keep up... or recover (I'm thinking of the OOo Bugzilla as an example where there were bugs open for 4, 5, or even 6 years or more). Just some thoughts that are passing through my mind... Is anyone assigned to triage all incoming bug reports or do we rely on an automated system? Does someone take the time to actually read each bug report and validate it in some way before it's dumped on a maintainer's doorstep... make sure it has useful information, log files etc? If not, it would be a good opportunity for someone, or several someones, who is/are not a skilled developer to step up and contribute. Does anyone comb through the (old) open bug reports after a release and flag them? Does every bug report have a milestone set? A realistic milestone? What happens if the milestone passes and the bug is still open? Are there bug reports open for more than some arbitrary period (say 6 months, and yes, I know, there are bugs that have been open for several years.. it's a rhetoric question)? Can someone wade through the bug reports older than X months (for some value of X), and for any that are not obviously in process, ping the reporter (or maybe owner) to see if they are still valid/required (without it becoming a spam-fest for the maintainer)? Does any one maintainer have a disproportionate number of open bugs that are not getting attention? (not to say someone is slacking, but that they have way more than they can deal with due to workload, time, effort required ect.) C. -- openSUSE 12.1 x86_64, KDE 4.8.2 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 04/27/2012 10:28 AM, C wrote:

On Fri, Apr 27, 2012 at 10:09, Per Jessen wrote:

...

This thread is from -factory, but it applies to the project overall:

Are there bug reports open for more than some arbitrary period (say 6 months, and yes, I know, there are bugs that have been open for several years.. it's a rhetoric question)? Can someone wade through the bug reports older than X months (for some value of X), and for any that are not obviously in process, ping the reporter (or maybe owner) to see if they are still valid/required (without it becoming a spam-fest for the maintainer)?

There used to be a bugfix event, I am using past tense, as can't recall a recent one done lately. Maybe before going gold for 12.2 there should be a bug-fest focusing on closing bugs with some kind of carrot for the rabbit. Togan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Dne Pá 27. dubna 2012 12:55:24 Per Jessen napsal(a):

C wrote:

...

This isn't unique to openSUSE. Most project Bugzillas are overwhelmed. Small number of people trying to deal with a large workload. Once the bug reporting system is overwhelmed, it's hard to keep up... or recover (I'm thinking of the OOo Bugzilla as an example where there were bugs open for 4, 5, or even 6 years or more).

Just some thoughts that are passing through my mind...

Is anyone assigned to triage all incoming bug reports or do we rely on an automated system? Does someone take the time to actually read each bug report and validate it in some way before it's dumped on a maintainer's doorstep... make sure it has useful information, log files etc?

Yes, I think someone is assigned - every now and then, I see reports being re-assigned by "kkzhang@suse.com" whom I assume is part of a triage team.

...

Does anyone comb through the (old) open bug reports after a release and flag them?

Judging by my list of open reports, no.

...

Does every bug report have a milestone set? A realistic milestone? What happens if the milestone passes and the bug is still open?

Expected-Time-To-Repair? Not that I'm aware of, but it might be nice for a reporter to set a kind of deadline, then have the report closed automatically as "CANTFIX::TIMEOUT". (or something appropriate for that situation).

...

Are there bug reports open for more than some arbitrary period (say 6 months, and yes, I know, there are bugs that have been open for several years.. it's a rhetoric question)? Can someone wade through the bug reports older than X months (for some value of X), and for any that are not obviously in process, ping the reporter (or maybe owner) to see if they are still valid/required (without it becoming a spam-fest for the maintainer)?

I do occasionally do this for my own reports, but really only the ones I depend on.

FWIW all of the above is done as part of L3 Support for enterprise systems, and it costs quite some engineering time (read: lots of money). I doubt any company will provide this service for free. So, let's define a lesser goal that would still improve the situation with minimum effort. For starter, what about setting X to 6 months and closing bug reports automatically if there is no update for longer than that? Petr Tesarik -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Larry Finger wrote:

On 04/27/2012 11:07 AM, Petr Tesarik wrote:

...

So, let's define a lesser goal that would still improve the situation with minimum effort. For starter, what about setting X to 6 months and closing bug reports automatically if there is no update for longer than that?

Perhaps 6 months would be too short; however, there are a lot of open bugs that refer to releases that are no longer supported.

The Testing Core Team has run several Open-Bugs-Days. Although they are usually run after MS5 of a new release, we held one event for old bugs, and had very little participation! I concentrated on the really old ones with IDs < 400000. I closed about 150 of them with a WONT-FIX with a comment that the affected release was out of support and asking them to re-open if the problem still was present in the current release (11.4). There were no more than 15 re-opened. On reflection, I should have told them to open a new bug, not re-open the old one.

Hi Petr, Larry I was really just trying to provoke a reaction when I suggested that - I don't think automatically closing bugs is the right thing to do, and exactly what it would improve on isn't very clear either. It might very well just pee off people that take the time to report bugs. I haven't thought this through, but maybe we need to describe a) the problem and b) what causes it before we c) try to come with a solution? As a side note, any solution we consider ought to also take the openSUSE version into account - Factory, current, supported, EOL. Here's my view of the problem: The processing of bug reports takes much too long. I think this is bad for the project overall, as it indirectly discourages people from reporting bugs. (Bugzilla can be a bit of steep learning curve, but it's only made worse when your report _appears_ to be ignored once you've finally scaled it.) Interestingly (perhaps), some bugs are processed in a perfectly timely manner. In the last two-three weeks, I have filed a couple of reports on kernel issues, one is already fixed and closed, one is in progress. Wrt the causes, I'm guessing it's primarily a matter of resources. -- Per Jessen, Zürich (21.8°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org