Re: GCC 3.3.1 and GCC 3.4 Schedule

["Giovanni Bajo" <giovannibajo at libero dot it>]

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

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.

>> which could be used automatically by scripts & query to
>> find out regressions and setup milestones. Any other solution I've seen
>> leads to either an information duplication or a loss of information.
>> Until
>> we find out what to do and do it, I'd rather keep the current system.
>
> What version a bug needs to be fixed *by* is the milestone.
> The fact that it may affect multiple versions is a separate issue.
> There is *always* an earliest version which we plan to fix it by, if
> it's a regression.

Yes, but it's kind of fixed assignment. If it's a 3.3 regression, it's 3.3.1
right now (or "next 3.3 dot release"). If it's a 3.4 regression, it's 3.4.
If it's not a regression, there is no milestone. In other words, this field
could be calculated automatically if the database stored enough information
about the regression status (like in my example).

Giovanni Bajo