bugs audit volunteers required

[Vijay Kiran Kamuju]

Hi,

just like last year we did an audit of all the bugs in bugzilla.
I think this year also we should do the same, the bugs are growing
large  and older bugs are being neglected.
just wanted to say  that we need to check all the old open bugs, and
test them/ask the user for status.
Close the bug as Abandoned if there is no response. also test the
application yourself on latest git.
this is the work to be done. and we need volunteers for this work.

need volunteers to clear up the mess(old abandoned bugs) in bugzilla

Thanks,
vj

[Austin English]

I've been doing this a little bit at a time for a while. I just wanted
to check base and make sure all on the same page. For starters, here's
a search of all bugs not touched in 6 months:
http://bugs.winehq.org/buglist.cgi?query_format=advanced&short_desc_type...
Which is the main list I work from for triaging old bugs. Here's
another link with bugs that have a download available:
http://bugs.winehq.org/buglist.cgi?query_format=advanced&short_desc_type...

Furthermore, what criteria are we using for considering a bug
abandoned? I've been closing bugs that have had a lingering
question/request (e.g., requested a log/test) but received no reply in
6 months.

Lastly, how long are we trying to do this over? I try to limit my
testing/requests so as to not spam everyone too much, but if we go
through and verify all these old bugs, it's going to be _a lot_ of
bugzilla activity. Is everyone prepared for/okay with that?

-Austin

On Dec 31, 2007 5:05 PM, Vijay Kiran Kamuju  wrote:
> Hi,
>
> just like last year we did an audit of all the bugs in bugzilla.
> I think this year also we should do the same, the bugs are growing
> large  and older bugs are being neglected.
> just wanted to say  that we need to check all the old open bugs, and
> test them/ask the user for status.
> Close the bug as Abandoned if there is no response. also test the
> application yourself on latest git.
> this is the work to be done. and we need volunteers for this work.
>
> need volunteers to clear up the mess(old abandoned bugs) in bugzilla
>
> Thanks,
> vj

[Vijay Kiran Kamuju]

On Dec 31, 2007 5:19 PM, Austin English  wrote:
> I've been doing this a little bit at a time for a while. I just wanted
> to check base and make sure all on the same page. For starters, here's
> a search of all bugs not touched in 6 months:
> http://bugs.winehq.org/buglist.cgi?query_format=advanced&short_desc_type...

Cool, I generally do it manually by checking every old bug <8000
> Which is the main list I work from for triaging old bugs. Here's
> another link with bugs that have a download available:
> http://bugs.winehq.org/buglist.cgi?query_format=advanced&short_desc_type...
>
> Furthermore, what criteria are we using for considering a bug
> abandoned? I've been closing bugs that have had a lingering
> question/request (e.g., requested a log/test) but received no reply in
> 6 months.

Generally we consider the bug as abandoned if the submitter does not
respond for more than 1yr(at least 6months).
Generally we consider the time factor if we could not get the application name.
or if the submitter does not clearly  explain the problem. (with to
implementation of features  or specialized test cases)
And we check whether it belongs to any of the metabugs already present.
Mostly for the older apps we would like to manually test ourselves
with the links provided.
As for the old bugs submitters might have forgotten about them.
So we need to test it ourselves and put the logs or somethiing like
still present in latest git.
> Lastly, how long are we trying to do this over? I try to limit my
> testing/requests so as to not spam everyone too much, but if we go
> through and verify all these old bugs, it's going to be _a lot_ of
> bugzilla activity. Is everyone prepared for/okay with that?

We would be doing this for 1-2 months as the Wine 1.0 release might
happen in may be next 6-7 months time. We might expect lotta bugzilla
activity as wine goes out of beta.
and all the old bugs will be ignored and bugs grow exponentially.
There will be lotta bugzilla spam, we cant avoid it ;)
Last time it was mostly done by Jonathan Ernst and others, also by me

--
VJ
> -Austin
>
> On Dec 31, 2007 5:05 PM, Vijay Kiran Kamuju  wrote:
> > Hi,
> >
> > just like last year we did an audit of all the bugs in bugzilla.
> > I think this year also we should do the same, the bugs are growing
> > large  and older bugs are being neglected.
> > just wanted to say  that we need to check all the old open bugs, and
> > test them/ask the user for status.
> > Close the bug as Abandoned if there is no response. also test the
> > application yourself on latest git.
> > this is the work to be done. and we need volunteers for this work.
> >
> > need volunteers to clear up the mess(old abandoned bugs) in bugzilla
> >
> > Thanks,
> > vj

[Maarten Lankhorst]

Vijay Kiran Kamuju schreef:
> just like last year we did an audit of all the bugs in bugzilla.
> I think this year also we should do the same, the bugs are growing
> large  and older bugs are being neglected.
> just wanted to say  that we need to check all the old open bugs, and
> test them/ask the user for status.
> Close the bug as Abandoned if there is no response. also test the
> application yourself on latest git.
> this is the work to be done. and we need volunteers for this work.
>
> need volunteers to clear up the mess(old abandoned bugs) in bugzilla

The situation with bugzilla is quite bad. The rate at which bugs are
opened is a LOT higher then the rate of bugs that can be fixed. This
adds a lot of bugs that won't ever be fixed.

The situation also isn't helped by the fact that a lot of the newly
generated bug reports are not of good enough quality. Example: "My
obscure app doesn't do xxx", without for example mentioning what the app
is, or a link to a demo, or insufficient information to really reproduce
the bug.

The situation isn't improved by the fact that bugs are reopened by those
persons after minimal additions. Perhaps we should have a bug
moderation? Only allow bugs that follow the criterion, then have a way
for bugzilla admins to accept bug reports and then a new bug report
entry is created in bugzilla.

-Maarten

[James McKenzie]

Maarten Lankhorst wrote:
> Vijay Kiran Kamuju schreef:
> > just like last year we did an audit of all the bugs in bugzilla.
> > I think this year also we should do the same, the bugs are growing
> > large  and older bugs are being neglected.
> > just wanted to say  that we need to check all the old open bugs, and
> > test them/ask the user for status.
> > Close the bug as Abandoned if there is no response. also test the
> > application yourself on latest git.
> > this is the work to be done. and we need volunteers for this work.
> >
> > need volunteers to clear up the mess(old abandoned bugs) in bugzilla
>
> The situation with bugzilla is quite bad. The rate at which bugs are
> opened is a LOT higher then the rate of bugs that can be fixed. This
> adds a lot of bugs that won't ever be fixed.

There are bugs that are related and these should be linked since the
Wine developers have
disallowed Metabugs.  Thus if a bug is dependent on a fix for .NET 2.0
for example, then the
bug should be linked into a report for .NET 2.0 installation not
completing.  Thus, the reporter
is aware that .NET has to be fixed first and then the reported bug can
be worked on.
> The situation also isn't helped by the fact that a lot of the newly
> generated bug reports are not of good enough quality. Example: "My
> obscure app doesn't do xxx", without for example mentioning what the app
> is, or a link to a demo, or insufficient information to really reproduce
> the bug.

I agree.  If you cannot find the application or a demo version to work
with, how can you fix the
bug.  Logs and other helpers go a long way.  Maybe an intro page as to
what is needed and how
to get it.  This will become more and more critical as the project
approaches 'release' status (1.0).
Also, marking bugs as having insufficient information to fix advises the
reporter that the project
needs more information to help or troubleshoot.
> The situation isn't improved by the fact that bugs are reopened by those
> persons after minimal additions. Perhaps we should have a bug
> moderation? Only allow bugs that follow the criterion, then have a way
> for bugzilla admins to accept bug reports and then a new bug report
> entry is created in bugzilla.

This would put a heavy load on the bug admins and actually slow down the
process.  I work on
other projects.  Clicking on the "NEW BUG" link should take a person to
a web page with reporting
criteria.  At this point, the reporter will read through a page of what
should be done to report a
bug.  After clicking a 'I read and understand the reporting
requirements', then the reporter will be
able to submit a bug.  After a few cycles of this, regular reporters
will not be subject to this page and
will be taken instead to the regular bug reporting page.  For the
occasional reporter, this is a good way
to handle bug reports, IMHO.

James

[Austin English]

On Dec 31, 2007 6:42 PM, James McKenzie  wrote:
> I agree.  If you cannot find the application or a demo version to work
> with, how can you fix the
> bug.  Logs and other helpers go a long way.  Maybe an intro page as to
> what is needed and how
> to get it.  This will become more and more critical as the project
> approaches 'release' status (1.0).
> Also, marking bugs as having insufficient information to fix advises the
> reporter that the project
> needs more information to help or troubleshoot.

Maybe add a resolution of NEEDMOREINFO?
> This would put a heavy load on the bug admins and actually slow down the
> process.  I work on
> other projects.  Clicking on the "NEW BUG" link should take a person to
> a web page with reporting
> criteria.  At this point, the reporter will read through a page of what
> should be done to report a
> bug.  After clicking a 'I read and understand the reporting
> requirements', then the reporter will be
> able to submit a bug.  After a few cycles of this, regular reporters
> will not be subject to this page and
> will be taken instead to the regular bug reporting page.  For the
> occasional reporter, this is a good way
> to handle bug reports, IMHO.

Agreed.

- Austin

[Vijay Kiran Kamuju]

On Dec 31, 2007 6:49 PM, Austin English  wrote:
> On Dec 31, 2007 6:42 PM, James McKenzie  wrote:
> > I agree.  If you cannot find the application or a demo version to work
> > with, how can you fix the
> > bug.  Logs and other helpers go a long way.  Maybe an intro page as to
> > what is needed and how
> > to get it.  This will become more and more critical as the project
> > approaches 'release' status (1.0).
> > Also, marking bugs as having insufficient information to fix advises the
> > reporter that the project
> > needs more information to help or troubleshoot.
>
> Maybe add a resolution of NEEDMOREINFO?

+1 vote from  me
> > This would put a heavy load on the bug admins and actually slow down the
> > process.  I work on
> > other projects.  Clicking on the "NEW BUG" link should take a person to
> > a web page with reporting
> > criteria.  At this point, the reporter will read through a page of what
> > should be done to report a
> > bug.  After clicking a 'I read and understand the reporting
> > requirements', then the reporter will be
> > able to submit a bug.  After a few cycles of this, regular reporters
> > will not be subject to this page and
> > will be taken instead to the regular bug reporting page.  For the
> > occasional reporter, this is a good way
> > to handle bug reports, IMHO.
>
> Agreed.

+1 vote from me
Page should contain some info like  critical info we need like  logs,
etc, steps  to reproducec, download  link.  (check ubuntu launchpad).
It should automatically  create the bug in bugzilla, based on that info.
--
VJ
> - Austin

[Jan Zerebecki]

On Mon, Dec 31, 2007 at 06:49:56PM -0600, Austin English wrote:
> On Dec 31, 2007 6:42 PM, James McKenzie  wrote:
> > I agree.  If you cannot find the application or a demo version to work
> > with, how can you fix the
> > bug.  Logs and other helpers go a long way.  Maybe an intro page as to
> > what is needed and how
> > to get it.  This will become more and more critical as the project
> > approaches 'release' status (1.0).
> > Also, marking bugs as having insufficient information to fix advises the
> > reporter that the project
> > needs more information to help or troubleshoot.
>
> Maybe add a resolution of NEEDMOREINFO?

We could add flags for "needs more information" and perhaps one
for "reproducible bug report with enough initial information".

(A flag is something that can be requested to be set and can then
be granted or denied by someone who was given the required rights.)
> > Clicking on the "NEW BUG" link should take a person to
> > a web page with reporting
> > criteria.  At this point, the reporter will read through a page of what
> > should be done to report a
> > bug.  After clicking a 'I read and understand the reporting
> > requirements', then the reporter will be
> > able to submit a bug.  After a few cycles of this, regular reporters
> > will not be subject to this page and
> > will be taken instead to the regular bug reporting page.  For the
> > occasional reporter, this is a good way
> > to handle bug reports, IMHO.

Our bugzilla is in git, patches are welcome.

I think a small and easy explanation on the new-bug form, that
refers one to a wiki page for the full guide is a good thing.

(I guess it's probably hard to filter bad bug reports
automatically and even harder to not inconvenience our good bug
reporters at the same time.)

Jan

[Austin English]

On Jan 1, 2008 9:33 AM, Jan Zerebecki  wrote:
> We could add flags for "needs more information" and perhaps one
> for "reproducible bug report with enough initial information".
>
> (A flag is something that can be requested to be set and can then
> be granted or denied by someone who was given the required rights.)

That could work as well.
> I think a small and easy explanation on the new-bug form, that
> refers one to a wiki page for the full guide is a good thing.
>
> (I guess it's probably hard to filter bad bug reports
> automatically and even harder to not inconvenience our good bug
> reporters at the same time.)

Maybe on the page for registering a bugzilla and/or on first login?

-Austin

[James McKenzie]

Jan Zerebecki wrote:
> On Mon, Dec 31, 2007 at 06:49:56PM -0600, Austin English wrote:
> > On Dec 31, 2007 6:42 PM, James McKenzie  wrote:
> > > I agree.  If you cannot find the application or a demo version to work
> > > with, how can you fix the
> > > bug.  Logs and other helpers go a long way.  Maybe an intro page as to
> > > what is needed and how
> > > to get it.  This will become more and more critical as the project
> > > approaches 'release' status (1.0).
> > > Also, marking bugs as having insufficient information to fix advises the
> > > reporter that the project
> > > needs more information to help or troubleshoot.
> >
> > Maybe add a resolution of NEEDMOREINFO?
>
> We could add flags for "needs more information" and perhaps one
> for "reproducible bug report with enough initial information".
>
> (A flag is something that can be requested to be set and can then
> be granted or denied by someone who was given the required rights.)

A resolution is much better.  Using a flag of needsmoreinfo usually does
not get answered.
> > > Clicking on the "NEW BUG" link should take a person to
> > > a web page with reporting
> > > criteria.  At this point, the reporter will read through a page of what
> > > should be done to report a
> > > bug.  After clicking a 'I read and understand the reporting
> > > requirements', then the reporter will be
> > > able to submit a bug.  After a few cycles of this, regular reporters
> > > will not be subject to this page and
> > > will be taken instead to the regular bug reporting page.  For the
> > > occasional reporter, this is a good way
> > > to handle bug reports, IMHO.
>
> Our bugzilla is in git, patches are welcome.
>
> I think a small and easy explanation on the new-bug form, that
> refers one to a wiki page for the full guide is a good thing.

I like the recommendation that a page be read before submitting bugs. 
There are a growing number of duplicates (I'm responsible for at least
one of them and I've been at the bug business for a long time) and
incomplete reports points to the need for a readme type of page.  The
regulars should not be subject to reading the page (this could be a
cookie function that just counts the number of bugs submitted and should
be a very simple cookie as far as name and function.)
> (I guess it's probably hard to filter bad bug reports
> automatically and even harder to not inconvenience our good bug
> reporters at the same time.)

+1 to this.  Automatic filtering can lead to some necessary reports
being skipped or deleted when additional, useful information will make
them usable.

Thank you for taking time to read through my suggestions as well.

One last comment, the OpenOffice.org project (I think) stopped the
ability for anyone without the canconfirm permission to reopen a bug.  I
might want to look at this in the future if time allows.

James

[Dmitry Timoshkov]

"Austin English"  wrote:
> > Also, marking bugs as having insufficient information to fix advises the
> > reporter that the project
> > needs more information to help or troubleshoot.
>
> Maybe add a resolution of NEEDMOREINFO?

There is no need to add one more reason for a bug resolution IMHO,
INVALID with appropriate comment does the job.

[Kai Blin]

On Wednesday 02 January 2008 05:14:00 Dmitry Timoshkov wrote:
> "Austin English"  wrote:
> > > Also, marking bugs as having insufficient information to fix advises the
> > > reporter that the project
> > > needs more information to help or troubleshoot.
> >
> > Maybe add a resolution of NEEDMOREINFO?
>
> There is no need to add one more reason for a bug resolution IMHO,
> INVALID with appropriate comment does the job.

As far as I've seen NEEDMOREINFO used in bugzilla, it is on the same level as 
NEW, ACCEPTED and FIXED. So new bugs come in as new, and someone looks at 
them and accepts the bug if the information is complete enough to work on the 
bug, and sets it to FIXED INVALID or NEEDMOREINFO if it's invalid or doesn't 
have enough information to reproduce it.

So far I've always left a bug on NEW until I could reproduce it, NEEDMOREINFO 
would be more clear, but I don't feel very strong about this either way.

Cheers,
Kai