Bug tracking organization

[Andreas Mohr]

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 ?

I'd suggest the following layout:

0.9.0
  Presentation metabug
    Documentation
    Website
    Stable packaging (.deb, .rpm, .tar.gz)
    programs metabug (what WineLib programs to supply ?)
  GUI metabug
    window management metabug
    messaging metabug
    common controls metabug
    shell namespace
    fonts/printing metabug
  multimedia metabug
    dsound
    winmm
    directx (direct3d etc.)
    opengl
    video
  DLL separation metabug
  RPC/wineserver metabug
    OLE metabug (ok, not 100% correct, but main hole is DCOM RPC stuff)
  lowlevel metabug
    file system metabug
      registry
      profile
      lzexpand
    memory management metabug
    loader metabug
      PE
      NE
      DOS metabug
  comm metabug
    winsock
    wininet, icmp, url, urlmon, snmpapi, mapi32, netapi32
    serial
    TAPI
  "developer stuff" metabug
    WineLib
    winedbg
    regression testing/test suite metabug
    msvcrt, msvcrt20, crtdll
  Misc. metabug (for other stuff)
    twain, winaspi
  "others" metabug (in order to deposit bug reports of "alien" wine packages
  here)

Is this structure ok ?
How should it be reorganized, what should be changed ?
If we get to a final result, then I'll make sure the 0.9.0 bug gets to look
like that.

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).

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...

BTW, I'm currently subscribed to wine-bugs.
I guess I'll stay subscribed for a while, and once the initial bug tracking
structure is solid and doesn't need special attention, I'll be able to
concentrate on specific areas, and then I'll probably unsubscribe.

Any comments ?

[Francois Gouget]

On Sat, 11 May 2002, Andreas Mohr 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 ?

Two comments:
 * I think the proposed layout has way too many metabugs. It's easy to
deal with lists of at least up to 50 bugs. We don't want to have one
metabug for every 3 or 4 regular bug. So I don't think we need much in
the way of metabugs, especially in the 0.9.0 list. The only ones
currently are for the documentation (bug 75, and one per book:
77,78,79). These I inherited and while we could probably do with bug 75
and everything flat underneath I consider it unnecessary to reorganize.
The other one is for the dll separation work (bug 96, has 20 subbugs)
and bug 655 which you created.

* most of the tasks you propose are not on the list that we established
at WineConf 2002. To remain meaningful the 0.9.0 bug list should not
contain each and every known bug and task under the sun. We are not
going to fix them all before 0.9.0 or even before 1.0.

To refresh memories, here is the charter of the 0.9.0 release:
(from http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=35)

This is now a Meta Bug for 0.9.0 which will mark the start of our
    progress to 1.0 as discussed at WineConf 2002:
    * when the items in this list have been completed, we release 0.9.0
    * at this point we should be ready to have increased user
      participation for using, testing and documenting Wine.
    * during 0.9.1, 0.9.2, etc. we do a progressive code freeze
    * then when everything is frozen we release 1.0
    * after 1.0.0 we will have stable and unstable branches

Note that Wine 0.9.0/1.0.0 does not mean that Wine
    will run all Windows applications. It means that:
    * Wine is ready for use by the general public for selected
      applications
    * that applications based on an old version of Wine/Winelib will
      work with a new version of the Wine server.
    * that the stable branches of Wine should not suffer major
      regressions. An application that works in 1.0.x should work in
      1.0.y if y>x.

Please correct me if you feel that the above does not reflect what was
discussed at WineConf2002.

Probably, most of the tasks you want to add in the 0.9.0 list could go
into the general tasklist, aka bug 395:
http://wine.codeweavers.com/bugzilla/showdependencytree.cgi?id=395

Now on to specific items:

[...]
> Presentation metabug
>     Documentation
>     Website
>     Stable packaging (.deb, .rpm, .tar.gz)

This has been discussed multiple times and the conclusion was that
packaging is not really part of the core of Wine. However, if you know
of specific things to improve in the 'Wine Packagers Guide'
(http://www.winehq.com/Docs/wine-pkg/) then we could add these to the
general task list.
> programs metabug (what WineLib programs to supply ?)

I don't think we need a metabug for that. When we realize there is a
need to provide a specific application (such as regedit or regsvr32),
then all that is needed is to create a

[...]
> multimedia metabug
>     dsound
>     winmm
>     directx (direct3d etc.)
>     opengl
>     video

These are good but should be in the general tasklist. You need to be
more specific though. E.g. what do you have in mind for winmm? Or rather
than just dsound we could list 3D DirectSound support. (but I guess you
did not want to expand too much in this list ;-)
One thing that would be useful is a description of what we need for
Direct3D support and what are the main tasks to get Direct3D support.
Another which would fall under the 'video' heading is adding support for
XVideo to DirectDraw.

[...]
> lowlevel metabug
>     file system metabug
>       registry
>       profile
>       lzexpand
>     memory management metabug
>     loader metabug
>       PE
>       NE
>       DOS metabug
>   comm metabug
>     winsock
>     wininet, icmp, url, urlmon, snmpapi, mapi32, netapi32
>     serial
>     TAPI
>   "developer stuff" metabug
>     WineLib
>     winedbg
>     regression testing/test suite metabug
>     msvcrt, msvcrt20, crtdll
>   Misc. metabug (for other stuff)
>     twain, winaspi
>   "others" metabug (in order to deposit bug reports of "alien" wine packages
>   here)

Same thing for all of this. What we need is more specific items that
need to be fix with a good description of the work to do rather than 30+
empty metabugs.

--
Francois Gouget         [e-mail]        http://fgouget.free.fr/
                            $live{free} || die "";

[Steven Edwards]

> "developer stuff" metabug
>     WineLib
>     winedbg
>     regression testing/test suite metabug
>     msvcrt, msvcrt20, crtdll
>   Misc. metabug (for other stuff)
>     twain, winaspi
>   "others" metabug (in order to deposit bug reports of 
> "alien" wine packages
>   here)

I would like to see the mingw/cygwin/ms_vc ports or a porting metabug
under 
developer stuff. The DLL seperation in wine 1.0 is a dependancy the
ReactOS 
project has. Only the dlls, programs and tools really matter for mingw
and MS_VC so I think that can be reached for wine 1.0. I still want to
do a cygwin port of wineserver 
But as long as dll seperation is done then it can wait till wine 1.x

Thanks
Steven

[Andriy Palamarchuk]

--- Andreas Mohr  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

[Alexandre Julliard]

Andriy Palamarchuk  writes:
> The third line of the bugs handling already exists. It
> is called wine-devel ;-)

I think that wine-devel should be the second line too, i.e. as soon as
you have enough information to assign the bug to one of the component
owners, you should send a note to wine-devel at the same time so that
other developers can jump in if they know the solution.

[Andriy Palamarchuk]

--- Alexandre Julliard  wrote:
> Andriy Palamarchuk  writes:
> > The third line of the bugs handling already
>
> exists. It
> > is called wine-devel ;-)
>
> I think that wine-devel should be the second line
> too, i.e. as soon as
> you have enough information to assign the bug to one
> of the component
> owners, you should send a note to wine-devel at the
> same time so that
> other developers can jump in if they know the
> solution.

I do not mind as soon as it won't clutter the list.
We can try it anyway.
The notification should be optional. We can automate
this with corresponding form in Bugzilla:

[x] Notify wine-devel

Notification:
 _________
[         ]
[         ]
[         ]
 ---------

Andriy Palamarchuk

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com