Assigning bugs, and how new developers can find bugs to work on
Hi Paul, I was wondering what is the best way to pick bugs, for a developer aspiring to fix nonspecific Wine bugs. Normally, our hero would look at the unassigned bugs to find one to work on. For some bugs, a fix appeared with no notification that somebody is working on them, for example: http://bugs.winehq.org/show_bug.cgi?id=22263 - julliard@ unexpectedly announced that the bug should be fixed by a specific patch. http://bugs.winehq.org/show_bug.cgi?id=22845 - arethusa26@ unexpectedly mentioned that the bug should be fixed by somebody else's specific patch. Notice both are marked as FIXED, but none of them have been assigned! Let's say our hero picks a bug; should he ask on the bug page whether anybody is already working on it, or ask on wine-devel, or #wine-hackers? Or is it fine to just announce, in the bug page, that you'll work on that bug? See, for example, this comment: http://bugs.winehq.org/show_bug.cgi?id=22264#c9 Any suggestions about improving this process are welcome. I think people will show up, wanting to help, and it would be nice to help them find something to work on fast. ;) In the meanwhile, please assign the bugs, and spare others of spending time on them. As a bonus, it would be nice to see accurate numbers about how many bugs are on nobody's plate vs how many are on somebody's plate. Data! :) At the moment, there are 15 assigned bugs (ignored 11 assigned to wine-bugs@), vs 5580 unconfirmed/new/reopened bugs, for the Wine component. Thanks, Alex On Thu, May 27, 2010 at 20:00, Paul Vriens <paul.vriens.wine(a)gmail.com>wrote:
On 05/27/2010 07:48 PM, belnac wrote:
What about dev work, is any available?
Did you ever have a look at our bugzilla ;)
There is plenty of stuff to do besides fixing bugs of course. What you want to do depends on many things like skills, interest, the amount of time you have etc..
Remember that we are in code freeze now so looking at bugs and trying to figure out what could be wrong or even providing information that could lead to fixing the bugs is welcome.
-- Cheers,
Paul.
On 5/31/2010 20:01, Alexandru Băluț wrote:
Hi Paul,
I was wondering what is the best way to pick bugs, for a developer aspiring to fix nonspecific Wine bugs. Normally, our hero would look at the unassigned bugs to find one to work on. For some bugs, a fix appeared with no notification that somebody is working on them, for example:
http://bugs.winehq.org/show_bug.cgi?id=22263 - julliard@ unexpectedly announced that the bug should be fixed by a specific patch. Unexpectedly is very questionable word here cause it was a regression.
http://bugs.winehq.org/show_bug.cgi?id=22845 - arethusa26@ unexpectedly mentioned that the bug should be fixed by somebody else's specific patch. Anyone could retest a make a note about that.
Notice both are marked as FIXED, but none of them have been assigned! ASSIGNED state isn't used too often and there's nothing wrong with that.
Let's say our hero picks a bug; should he ask on the bug page whether anybody is already working on it, or ask on wine-devel, or #wine-hackers?
Pick whatever you want, read through comments to figure out does somebody work on it or not and write a fix.
Or is it fine to just announce, in the bug page, that you'll work on that bug? See, for example, this comment: http://bugs.winehq.org/show_bug.cgi?id=22264#c9
That's fine.
Any suggestions about improving this process are welcome. I think people will show up, wanting to help, and it would be nice to help them find something to work on fast. ;)
There's nothing to improve. You could search by component or any way you want.
In the meanwhile, please assign the bugs, and spare others of spending time on them. As a bonus, it would be nice to see accurate numbers about how many bugs are on nobody's plate vs how many are on somebody's plate. Data! :) At the moment, there are 15 assigned bugs (ignored 11 assigned to wine-bugs@), vs 5580 unconfirmed/new/reopened bugs, for the Wine component.
Why do you need this? git log/blame shows all stats on every person. It's a waste of time IMO to go with these ASSIGNED/VERIFIED. P.S. also I think our bugzilla setup allows to much currently. Along with practically unused states I mentioned already there's a difficulty field that needs to be removed; it's nice to tweak CC list a bit too to block reporter from being CCed.
Thanks, Alex
Hi Nikolay, On Mon, May 31, 2010 at 18:27, Nikolay Sivov <nsivov(a)codeweavers.com> wrote:
On 5/31/2010 20:01, Alexandru Băluț wrote:
Hi Paul,
I was wondering what is the best way to pick bugs, for a developer aspiring to fix nonspecific Wine bugs. Normally, our hero would look at the unassigned bugs to find one to work on. For some bugs, a fix appeared with no notification that somebody is working on them, for example:
http://bugs.winehq.org/show_bug.cgi?id=22263 - julliard@ unexpectedly announced that the bug should be fixed by a specific patch.
Unexpectedly is very questionable word here cause it was a regression.
The bissection did pinpoint the commit that caused the bug, and its author, but you still have to read the comments to figure that out, when it would have been easier to immediately see that the bug is assigned, and just leave it alone. (I'm talking from the point of view of a newbie Wine developer who is looking for a bug to fix.) http://bugs.winehq.org/show_bug.cgi?id=22845
- arethusa26@ unexpectedly mentioned that the bug should be fixed by somebody else's specific patch.
Anyone could retest a make a note about that.
Yes, anyone who retests can make a note about that.
Notice both are marked as FIXED, but none of them have been assigned!
ASSIGNED state isn't used too often and there's nothing wrong with that.
I'm not saying it's wrong if people don't use it, I'm saying it's useful when people use it.
Let's say our hero picks a bug; should he ask on the bug page whether anybody is already working on it, or ask on wine-devel, or #wine-hackers?
Pick whatever you want, read through comments to figure out does somebody work on it or not and write a fix.
Or is it fine to just announce, in the bug page, that you'll work on that bug? See, for example, this comment: http://bugs.winehq.org/show_bug.cgi?id=22264#c9
That's fine.
Ok. I personally don't like to pollute the bug log with "I'll work on this" messages. But I guess for newbie developers, who don't have bugzilla rights to change the Assigned field, it's the only solution. Any suggestions about improving this process are welcome. I think people
will show up, wanting to help, and it would be nice to help them find something to work on fast. ;)
There's nothing to improve. You could search by component or any way you want.
I realized while writing this email.. the process of searching a bug nobody is working on can be improved.
In the meanwhile, please assign the bugs, and spare others of spending time on them. As a bonus, it would be nice to see accurate numbers about how many bugs are on nobody's plate vs how many are on somebody's plate. Data! :) At the moment, there are 15 assigned bugs (ignored 11 assigned to wine-bugs@), vs 5580 unconfirmed/new/reopened bugs, for the Wine component.
Why do you need this? git log/blame shows all stats on every person. It's a waste of time IMO to go with these ASSIGNED/VERIFIED.
The git log shows what you did. This would show how much you have to do (rough approximation, of course). btw, how exactly do you keep track of what you have to do? Having bugs assigned looks like a way of managing your todo-s. Thanks, Alex
On 6/1/2010 02:56, Alexandru Băluț wrote:
In the meanwhile, please assign the bugs, and spare others of spending time on them. As a bonus, it would be nice to see accurate numbers about how many bugs are on nobody's plate vs how many are on somebody's plate. Data! :) At the moment, there are 15 assigned bugs (ignored 11 assigned to wine-bugs@), vs 5580 unconfirmed/new/reopened bugs, for the Wine component.
Why do you need this? git log/blame shows all stats on every person. It's a waste of time IMO to go with these ASSIGNED/VERIFIED.
The git log shows what you did. This would show how much you have to do (rough approximation, of course). btw, how exactly do you keep track of what you have to do? Having bugs assigned looks like a way of managing your todo-s.
You're overestimating a value of this tracking process. Currently a really long bug list is available, all you need is to choose a bug that fits your interests, put a note and start to fix it.
Thanks, Alex
On Tue, Jun 1, 2010 at 1:56 AM, Alexandru Băluț <alexandru.balut(a)gmail.com> wrote:
The git log shows what you did. This would show how much you have to do (rough approximation, of course). btw, how exactly do you keep track of what you have to do? Having bugs assigned looks like a way of managing your todo-s.
One way is to add yourself to the bug's CC list (you'll probably want that anyway, since if you're working on that bug you're interested if anybody posts updates), then save a search that lists bugs which have you in the CC field: hit Search on the toolbar, set criteria, Search, then fill in the field next to "Remember search as" and click the button. A new item will appear on the left in "Saved Searches". Hope it helps, Octavian
participants (3)
-
Alexandru Băluț -
Nikolay Sivov -
Octavian Voicu