Re: bugs audit volunteers required
On Mon, Dec 31, 2007 at 05:49:14PM -0700, James McKenzie wrote: Austin English wrote: On Dec 31, 2007 6:10 PM, Maarten Lankhorst [EMAIL PROTECTED] wrote: 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. Does bugzilla support this? How about not allowing someone without higher bugzilla privileges to reopen bugs? It should. Some of the other projects I work on will only allow a person with admin level to change the status of a submitted bug, including re-opening. I would also like to see this with bugzilla, even though I am an ordinary 'user'. This would prevent users from closing a bug report and then opening it again, even if the problem affects a different module. IMHO, these are two separate bugs. If you know how to configure bugzilla to prevent the bug creator from reopening it, I'd like to hear about it (AFAIK it's not possible). As far as I remember regular users who are not the creator are already disallowed from changing the resolution. Jan
Re: bugs audit volunteers required
On Jan 1, 2008 9:33 AM, Jan Zerebecki [EMAIL PROTECTED] 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
bugs audit volunteers required
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
Re: bugs audit volunteers required
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=advancedshort_desc_type=allwordssubstrshort_desc=product=Winelong_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=days_elapsedtype0-0-0=greaterthanvalue0-0-0=180 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=advancedshort_desc_type=allwordssubstrshort_desc=product=Winelong_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=days_elapsedtype0-0-0=greaterthanvalue0-0-0=180field0-1-0=keywordstype0-1-0=allwordssubstrvalue0-1-0=download 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 [EMAIL PROTECTED] 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
Re: bugs audit volunteers required
On Dec 31, 2007 5:56 PM, Vijay Kiran Kamuju [EMAIL PROTECTED] wrote: 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 I've got some spare time/bandwith to do this, but had been holding back to prevent the flood of bugzilla mail. But like you said, this needs to be done before 1.0, so if we're ready to do it now, I'll start triaging a lot more old stuff. I'll wait a day or so to get some more replies before though. On Dec 31, 2007 6:10 PM, Maarten Lankhorst [EMAIL PROTECTED] wrote: 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 Does bugzilla support this? How about not allowing someone without higher bugzilla privileges to reopen bugs?
Re: bugs audit volunteers required
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
Re: bugs audit volunteers required
Austin English wrote: On Dec 31, 2007 6:10 PM, Maarten Lankhorst [EMAIL PROTECTED] wrote: 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 Does bugzilla support this? How about not allowing someone without higher bugzilla privileges to reopen bugs? It should. Some of the other projects I work on will only allow a person with admin level to change the status of a submitted bug, including re-opening. I would also like to see this with bugzilla, even though I am an ordinary 'user'. This would prevent users from closing a bug report and then opening it again, even if the problem affects a different module. IMHO, these are two separate bugs. James McKenzie
Re: bugs audit volunteers required
On Dec 31, 2007 6:42 PM, James McKenzie [EMAIL PROTECTED] 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
Re: bugs audit volunteers required
On Dec 31, 2007 6:49 PM, Austin English [EMAIL PROTECTED] wrote: On Dec 31, 2007 6:42 PM, James McKenzie [EMAIL PROTECTED] 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
