Bugs and versions affected (Was Re: GCC 3.3.1 and GCC 3.4 Schedule)

[Daniel Berlin <dberlin at dberlin dot org>]

On Thursday, June 12, 2003, at 05:50  AM, Giovanni Bajo wrote:

> Daniel Berlin <dberlin@dberlin.org> wrote:
>
> > >  We had some discussion and
> > > I strongly believe that the best way would be to have a more powerful
> > > way to
> > > track which versions are affected by the bug (like a yes/no/untested
> > > flag
> > > for each version),
>
> > Which is horrific from a UI perspective.  Try coming up with a usable
> > interface.
>
> We could for instance have two edit boxes (like the one for keywords),
> namely "versions affected by the bugs", "versions not affected by the 
> bugs",
Immediately, people would complain they want a selection box.

> containing a comma-separated list of versions (or "mainline" for bugs
> affecting the CVS trunk). If a version is not listed in either of the 
> boxes,
> it means that it's untested. With this simple information, we could:
>
> - Automatically calculate/query which is a regression and which is not.
This assumes the information entered is correct.

> - Automatically set milestones for fixing. Actually, we wouldn't need 
> the
> milestone field anymore (at least as it is now), since it's 
> automatically
> chosen given the regression status.
So you want it to auto-set a milestone based on other fields?

> - Have a script to automatically add "3.4" to all bugs 
> affected/not-affected
> on "mainline", when we branch for 3.4, and similar.

> - Have a script to automatically close all the bugs not present 
> anymore on
> open branches, when we close an open branch.

Now you want branches, too, or do you mean release branches?

> - Have a check to prevent bug from being confirmed if their status on 
> open
> branches is not correctly reported in the fields (not sure for weird 
> targets
> and bootstrap stuff, but this should hold for most of the bugs anyway).
Huh?

> To be fair, this design is only missing a way to let the RM specify 
> that a
> regression will not be fixed in the next dotrelease of the affected 
> branch
> (it's postponed). To do that, we probably need to keep the "milestone"
> field, but we could still automatically keep it in sync with
> affected-version changes.

I'm willing to give this scheme a try if you like, but it's going to 
take some time.

Does everyone *else* want this scheme too?