Re: 3.4 regressions: are 2.95 regressions still actual

[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
  "critical" severity.

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"?

Regards,
Volker