We already had discussion on wine-devel about importance of polishing Wine, making a set of applications to work very well. Cruicial in this process is prioritizing of the issues, work distribution between developers. The companies already have internal testing and bug fixing process. Of course, each company has their own product-specific work, but most of the problems are general for Wine. I suggest to share this work more actively using Bugzilla. Recently there was some work done in cleaning the issues database and it is in pretty much usable condition. To start using bugzilla more actively I suggest following steps: 1) define subsystem/direction owners. The owners will get their system-specific bugs. They won't necessary fix the bugs themselfs, but will have complete picture about all the issues in their subsystems and coordinate the bug fixing. Developers, please let me know your areas of expertese. I can overview Wine applications. 2) more formally define process of bugs handling and use this process. There is no high qualification needed to filter out bad bug reports, duplicates, request users for more information, attach relay trace to the bug, etc, etc. Result - developers will have to spend less time on discussion trivial bugs with users, will have better bug reports to work on, users will be more involved with more active feedback. Some users are very cooperative and some bug reports are really excellent! I see that Tony Lambregts, Michael Cardenas, others do a great work with the Bugzilla database. I'm also going to contribute some time for this. 3) Prioritize bugs. This is, probably, part of (2). Some bugs, while relatively easy to fix provide very big value for the end user. Often developers do not choose such issues to work on, exactly because these issues do not present challenge to them. BTW, I do not see a field "Priority" in the bugs entries. 4) Ask users to submit there problems in Bugzilla. Submitting Bugzilla report allows us to involve users more actively, persist their bug reports. Bugzilla is a more scalable approach than using mailing list only. Of course we still will discuss bugs on the mailing lists, bug big part of communication will be unloaded. There is a lot to do and discuss. For me the goal is to have this process not worse than in Mozilla project. This is impressive: http://webtools.mozilla.org/miscstats/ http://mothra.mozilla.org/webtools/miscstats/ I also like their bug report form: http://www.mozilla.org/quality/help/bugzilla-helper.html And this is for 1 application only! I'm sure Wine can generate much bigger volume of bug reports ;-) Look forward for your comments. Andriy __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
Andriy Palamarchuk wrote:
We already had discussion on wine-devel about importance of polishing Wine, making a set of applications to work very well.
Cruicial in this process is prioritizing of the issues, work distribution between developers. The companies already have internal testing and bug fixing process.
Of course, each company has their own product-specific work, but most of the problems are general for Wine. I suggest to share this work more actively using Bugzilla.
Recently there was some work done in cleaning the issues database and it is in pretty much usable condition.
To start using bugzilla more actively I suggest following steps: 1) define subsystem/direction owners. The owners will get their system-specific bugs. They won't necessary fix the bugs themselfs, but will have complete picture about all the issues in their subsystems and coordinate the bug fixing.
Developers, please let me know your areas of expertese. I can overview Wine applications.
Let me see if I have this right you want an inventory of who has what area of experise right. For example if a bug report seems to point to a problem with sockets you could in theory assign it to Martin Wick, or if the problem was with copy protection It could be assigned to Laurent Pinchart. Of course that assumes that both of them are ok with this. What exactly do you mean by overview applications? I'm guessing you mean the wine lib applications currently under /programs right? Anyway this would be very usefull to the people who want to triage bugzilla.
2) more formally define process of bugs handling and use this process. There is no high qualification needed to filter out bad bug reports, duplicates, request users for more information, attach relay trace to the bug, etc, etc. Result - developers will have to spend less time on discussion trivial bugs with users, will have better bug reports to work on, users will be more involved with more active feedback. Some users are very cooperative and some bug reports are really excellent! I see that Tony Lambregts, Michael Cardenas, others do a great work with the Bugzilla database. I'm also going to contribute some time for this.
Think if we can get a few more people to to help with this it would be better
3) Prioritize bugs. This is, probably, part of (2). Some bugs, while relatively easy to fix provide very big value for the end user. Often developers do not choose such issues to work on, exactly because these issues do not present challenge to them. BTW, I do not see a field "Priority" in the bugs entries.
The Severity field is for this and yes we should use it.
4) Ask users to submit there problems in Bugzilla. Submitting Bugzilla report allows us to involve users more actively, persist their bug reports.
Bugzilla is a more scalable approach than using mailing list only. Of course we still will discuss bugs on the mailing lists, bug big part of communication will be unloaded.
If there are no objections can we change the official documentation to say that bugzilla is the place to report bugs. I noticed that when the wineinstall script had a bug in it that it told the users to report it to wine-devel when it should point them to bugzilla. One other comment about this is that bugzilla's address is http://wine.codeweavers.com/bugs/ and I think it scares people away from using it. I have nothing against CodeWeavers but I think If bugzilla's address was http://www.winehq.com/bugzilla users would be certain it is the place for wine bugs
There is a lot to do and discuss. For me the goal is to have this process not worse than in Mozilla project. This is impressive: http://webtools.mozilla.org/miscstats/ http://mothra.mozilla.org/webtools/miscstats/
I also like their bug report form: http://www.mozilla.org/quality/help/bugzilla-helper.html
And this is for 1 application only! I'm sure Wine can generate much bigger volume of bug reports ;-)
Look forward for your comments. Andriy
__________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
to wine-devel when it should point them to bugzilla. One other comment about this is that bugzilla's address is http://wine.codeweavers.com/bugs/ and I think it scares people away from using it. I have nothing against CodeWeavers but I think If bugzilla's address was http://www.winehq.com/bugzilla users would be certain it is the place for wine bugs
Wouldn't http://bugs.winehq.com be even better? We can make that switch fairly readily, and we're cheerful to do so. (Okay, I'm cheerful to do so, Jeremy is going to kill me for adding to his workload <grin>). Cheers, Jer
I'm not going to even debate this one <g> http://bugs.winehq.com http://bugs.winehq.org http://bugs.codeweavers.com Are now all the same website. Use whatever Url makes you fell all warm and fuzzy. On Tue, 2002-04-30 at 10:18, Jeremy White wrote:
to wine-devel when it should point them to bugzilla. One other comment about this is that bugzilla's address is http://wine.codeweavers.com/bugs/ and I think it scares people away from using it. I have nothing against CodeWeavers but I think If bugzilla's address was http://www.winehq.com/bugzilla users would be certain it is the place for wine bugs
Wouldn't http://bugs.winehq.com be even better?
We can make that switch fairly readily, and we're cheerful to do so. (Okay, I'm cheerful to do so, Jeremy is going to kill me for adding to his workload <grin>).
Cheers,
Jer
-- __ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | .` / -_) | | / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon
--- Tony Lambregts <tony_lambregts(a)telusplanet.net> wrote:
Andriy Palamarchuk wrote: [... skipped ...]
Developers, please let me know your areas of expertese. I can overview Wine applications.
Let me see if I have this right you want an inventory of who has what area of experise right. For example if a bug report seems to point to a problem with sockets you could in theory assign it to Martin Wick, or if the problem was with copy protection It could be assigned to Laurent Pinchart. Of course that assumes that both of them are ok with this.
Of course, the responsibility is voluntary (as the whole project BTW :-). Suggested list (so far): * Guy L. Albertelli - GUI * Alexandre Julliard - wineserver, kernel * Marcus Meissner - printing * Andreas Mohr - documentation * Andriy Palamarchuk - winelib applications under "programs" directory (agreed). * Dimitrie O. Paun - GUI * Laurent Pinchart - copy protection * Eric Pouech - sound * Hidenori TAKESHIMA - quartz, DirectShow (is the scope too narrow?) * Dmitry Timoshkov - internationalization, Unicode, keyboard i/o * Martin Wick - sockets Do we need following directions, who are good owners: * DOS support * common controls * command-line handling * wine tools This list is *very* subjective. I went through the last month archives of wine-patches. Please, let me know if you agree or not, know other better owner for the subsystem, want to suggest new subsystem, any other comments are welcome.
What exactly do you mean by overview applications? I'm guessing you mean the wine lib applications currently under /programs right?
Correct, see above
2) more formally define process of bugs handling and use this process.
[... skipped ...]
I see that Tony Lambregts, Michael Cardenas, others do a great work with the Bugzilla database. I'm also going to contribute some time for this.
Think if we can get a few more people to to help with this it would be better
Completely agree with you. This is why I invited the companies testers for this work ;-) I'm sure we'll get more volunteers from Wine users as soon as we will be more responsive in Bugzilla. Anyway, the first priority is to start to actually move bugs throgh their lifecycle to the RESOLVED status and now the bottleneck is on status NEW.
3) Prioritize bugs. This is, probably, part of (2). Some bugs, while relatively easy to fix provide very big value for the end user. Often developers do not choose such issues to work on, exactly because these issues do not present challenge to them. BTW, I do not see a field "Priority" in the bugs entries.
The Severity field is for this and yes we should use it.
Not exactly. "Severity" is an importance for the end user - e.g. crash is the highest level of severity. "Priority" is an importance of the issue for us. E.g. crash of an application due to Wine not supporting vxd is severity "Critical" for the user, but priority is "Minor" for the Wine developers because we are not going to support vxd anyways. [... skipped ...]
If there are no objections can we change the official documentation to say that bugzilla is the place to report bugs. I noticed that when the wineinstall script had a bug in it that it told the users to report it to wine-devel when it should point them to bugzilla. One other comment about this is that bugzilla's address is http://wine.codeweavers.com/bugs/ and I think it scares people away from using it. I have nothing against CodeWeavers but I think If bugzilla's address was http://www.winehq.com/bugzilla users would be certain it is the place for wine bugs
Agree. Now enter bugs to bugzilla for these changes ;-) Andriy __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
Andriy Palamarchuk wrote:
--- Tony Lambregts <tony_lambregts(a)telusplanet.net> wrote:
Andriy Palamarchuk wrote:
[snip]
[snip]
Of course, the responsibility is voluntary (as the whole project BTW :-).
Suggested list (so far): * Guy L. Albertelli - GUI * Alexandre Julliard - wineserver, kernel * Marcus Meissner - printing * Andreas Mohr - documentation * Andriy Palamarchuk - winelib applications under "programs" directory (agreed). * Dimitrie O. Paun - GUI * Laurent Pinchart - copy protection * Eric Pouech - sound * Hidenori TAKESHIMA - quartz, DirectShow (is the scope too narrow?) * Dmitry Timoshkov - internationalization, Unicode, keyboard i/o * Martin Wick - sockets Do we need following directions, who are good owners: * DOS support * common controls * command-line handling * wine tools
* Dustin Navea - wine tools (scripts?) * Duane Clark - toolbar
This list is *very* subjective. I went through the last month archives of wine-patches. Please, let me know if you agree or not, know other better owner for the subsystem, want to suggest new subsystem, any other comments are welcome.
Could we can get some help to make this list somewhat complete, Please? [snip]
issues do not present challenge to them. BTW, I do not see a field "Priority" in the bugs entries.
The Severity field is for this and yes we should use it.
Not exactly. "Severity" is an importance for the end user - e.g. crash is the highest level of severity. "Priority" is an importance of the issue for us. E.g. crash of an application due to Wine not supporting vxd is severity "Critical" for the user, but priority is "Minor" for the Wine developers because we are not going to support vxd anyways.
To most users that encounter a bug the severity is "critical". It is up to the bug owners and triage to decide what is important. Mozzilla has a resolution "WON'T FIX" for some bugs. I think vxd is "WONT FIX". As a long term tester of Mozilla I can say with confidence that severity is a flag for triage and development not for bug reporters. [blocker] is the highest priority: for example something prevents wine from compiling. Anyway the way that mozilla uses bugzilla is not the only way to use it. We have the source code if we really want to change it. I just don't see that it is nesessary.
[... skipped ...]
If there are no objections can we change the official documentation to say that bugzilla is the place to report bugs. I noticed that when the wineinstall script had a bug in it that it told the users to report it to wine-devel when it should point them to bugzilla. One other comment about this is that bugzilla's address is http://wine.codeweavers.com/bugs/ and I think it scares people away from using it. I have nothing against CodeWeavers but I think If bugzilla's address was http://www.winehq.com/bugzilla users would be certain it is the place for wine bugs
Agree. Now enter bugs to bugzilla for these changes ;-)
I entered bugs for the first two, and the third seems to be resolved already. <grin> Tony Lambregts
--- Andriy Palamarchuk <apa3a(a)yahoo.com> wrote:
--- Tony Lambregts <tony_lambregts(a)telusplanet.net> wrote:
Of course, the responsibility is voluntary (as the whole project BTW :-).
Suggested list (so far): * Guy L. Albertelli - GUI * Alexandre Julliard - wineserver, kernel * Marcus Meissner - printing * Andreas Mohr - documentation * Andriy Palamarchuk - winelib applications under "programs" directory (agreed). * Dimitrie O. Paun - GUI * Laurent Pinchart - copy protection * Eric Pouech - sound * Hidenori TAKESHIMA - quartz, DirectShow (is the scope too narrow?) * Dmitry Timoshkov - internationalization, Unicode, keyboard i/o * Martin Wick - sockets Do we need following directions, who are good owners: * DOS support * common controls * command-line handling * wine tools
This list is *very* subjective. I went through the last month archives of wine-patches. Please, let me know if you agree or not, know other better owner for the subsystem, want to suggest new subsystem, any other comments are welcome.
Update: * wine tools: Dustin Navea IOW: I will help out with wine tools (bash/perl stuff) and when i can i will try to work on some actual wine bugs... knowing only enough c to bugfix can always be helpful... ;) -Dustin __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
----- Original Message ----- From: "Andriy Palamarchuk" <apa3a(a)yahoo.com> To: "Tony Lambregts" <tony_lambregts(a)telusplanet.net> Cc: "wine-devel" <wine-devel(a)winehq.com> Sent: Tuesday, April 30, 2002 12:08 PM Subject: Re: Bugzilla: A Call to Arms
Suggested list (so far): * Guy L. Albertelli - GUI
[snip] Whoa! I'll be glad to handle some of the common controls (especially rebar) but not the whole GUI. :) Guy
--- "Guy L. Albertelli" <galberte(a)neo.lrun.com> wrote:
----- Original Message ----- From: "Andriy Palamarchuk" <apa3a(a)yahoo.com> To: "Tony Lambregts" <tony_lambregts(a)telusplanet.net> Cc: "wine-devel" <wine-devel(a)winehq.com> Sent: Tuesday, April 30, 2002 12:08 PM Subject: Re: Bugzilla: A Call to Arms
Suggested list (so far): * Guy L. Albertelli - GUI
[snip]
Whoa! I'll be glad to handle some of the common controls (especially rebar) but not the whole GUI. :)
I agree with you - GUI is too general area. We can narrow the scope - give you only common controls or make a few people to own all GUI controls/issues... I prefer the first approach. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
participants (6)
-
Andriy Palamarchuk -
Dustin Navea -
Guy L. Albertelli -
Jeremy Newman -
Jeremy White -
Tony Lambregts