--- Andreas Mohr andi@rhlx01.fht-esslingen.de wrote:
Hi all,
I think our bug tracking is still a bit too chaotic. Thus I intend to get some info on what bug tracking should look like.
So far, we've got "Wine 0.9.0 TaskList" and "Wine 1.x WishList" as the two main metabugs.
IMHO Wine 0.9.0 TaskList is the main bug for all development work up to Wine 1.0. And Wine 1.x WishList is everything that will definitely not be included in Wine 1.0 (and possibly even more).
Now how about the layout of Wine 0.9.0 TaskList ?
[skipped]
In general I agree with Francois - I prefer more flat structure with a few really important metabugs.
OK, on to the next topic: How should we organize the bug work ? We need tons of people to take UNCONFIRMED bugs and make sure that they reach enough quality in order to be reassigned as NEW (I expect ~ 30% of all bugs to get dropped right away).
We have already a few people, including me who processes unhandled bugs little-by-little. I expect activity in this direction higher after bugs start to move from "NEW" status. I will compile a list of the first line bug handlers in the same way as for component owners.
Ideally bugs with status "RESOLVED" should be verified and closed, but this is not urgent.
The second line of bug tracking would be experienced developers that are mainly responsible for certain areas (like we already started to discuss). There might even be a third line of "emergency" people for the really tough cases...
I expect the component owners to start handle the bugs when developers of the first line can't get useful information any more. This will be in the case when the root cause is found or research becomes inefficient. Definition of inefficient research can be subjective or we can setup some timeframe (2-3 days).
The third line of the bugs handling already exists. It is called wine-devel ;-)
Andriy
__________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com