This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 3.4 regressions: are 2.95 regressions still actual


Volker Reichelt wrote:

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

It looks like it's not accurate enough, given this thread. I'm ok with your
proposed clarification.

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

I propose to have bugmasters decide the severity of the bug (which is supposed
to be the "perceived" severity from an user standpoint), and make "only the
Release Manager or a maintainer of the specific part of GCC affected by the
bug" able to reschedule the milestone.

Giovanni Bajo



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]