This is the mail archive of the
mailing list for the GCC project.
Re: 3.4 regressions: are 2.95 regressions still actual
- From: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>
- To: giovannibajo at libero dot it
- Cc: bangerth at ices dot utexas dot edu, gcc at gcc dot gnu dot org, s dot bosscher at student dot tudelft dot nl,mark at codesourcery dot com, gdr at integrable-solutions dot net, nathan at codesourcery dot com
- Date: Mon, 12 Jan 2004 16:29:41 +0100 (CET)
- Subject: Re: 3.4 regressions: are 2.95 regressions still actual
- Reply-to: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>
On 12 Jan, Giovanni Bajo wrote:
>> Our (extensively discussed) policy has been to mark all regressions
>> for the next release, and that only the RM should be allowed to slip
>> a PR to a later release (as this is a political, not a technical
>> decision). I would like to keep to this policy. Otherwise, we would
>> all start to assign milestones at our own priority.
> Strongly agreed. Steven made me note that this is not stated in our bug
> management html page. Volker, would you kindly take care of adding this policy
> to the html?
Ok. But I'm not sure about the details. We now have:
Regressions should be explicitly marked as such. The summary line should read
[branches-to-fix regression] rest-of-summary
where branches-to-fix is the list of maintained branches (separated by slashes)
that need fixing. In addition the target milestone should be set accordingly.
A regression should start with severity "critical" to bring it to attention.
It may be downgraded later if a defect is not important enough to justify
Is "In addition the target milestone should be set accordingly" accurate
enough or should we rather write "... the target milestone should be set
to the next release that needs fixing"? Any other suggestions?
The last sentence could be changed to "It may be downgraded or rescheduled
to a different target milestone later by the release manager if a defect is
not important enough to justify "critical" severity."
Or do we want different permissions for downgrading (e.g. everybody)
and rescheduling (e.g. RM)?
Btw, is it "release manager" or "Release Manager"?