GCC 3.3.1 and GCC 3.4 Schedule

[Daniel Berlin]

On Wednesday, June 11, 2003, at 06:29  PM, Giovanni Bajo wrote:

> Joseph S. Myers wrote:
>
>>> - the target milestone: there are 110 PRs targeted for 3.3.1
>>> - summary strings that start with "[3.3", of which there are 139.
>
>> And preferably, this information should leave the summaries, of which 
>> only
>> a limited amount is displayed in search results by default.  The 
>> detailed
>> information of exactly which branches something is a regression on 
>> could
>> be given in the form of keywords 3.3regression, 3.4regression, along 
>> with
>> the milestone to indicate the release intended for a fix.  Having too 
>> much
>> information in the summaries rather than separate was a kludge for 
>> GNATS.
>
> I agree that we need to eventually remove the informations from the
> synopsis. It's been already done for [diagnostic], it will be done 
> soon-ish
> for [TARGET] (Dara & Andrew are doing a good work updating all the
> host/build/target triplets in the bugs so that we don't need to stamp 
> in the
> synopsis anymore).
>
> Alas, we didn't come to an agreement over the regression issue. It's
> probably the most important issue and should be handled carefully. 
> Using the
> 3.3regression and 3.4regression keywords makes the "milestone" entry 
> almost
> a duplicate (like it is right now), and has some issues when in the 
> future
> we branch for 3.4 and/or we close the 3.3 branch.
What issues?

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

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

>
> Giovanni Bajo
>