On March 1, 2017 3:34:46 AM GMT+01:00, Martin Sebor <mse...@gmail.com> wrote:
>On 02/28/2017 01:41 PM, Richard Biener wrote:
>> On February 28, 2017 7:00:39 PM GMT+01:00, Jeff Law <l...@redhat.com>
>wrote:
>>> On 02/28/2017 10:54 AM, Martin Sebor wrote:
>>>> The GCC 7 release criteria page mentions Java even though
>>>> the front end has been removed.  The attached patch removes Java
>>>> from the criteria page.  While reviewing the rest of the text I
>>>> noticed a few minor typos that I corrected in the patch as well.
>>>>
>>>> Btw., as an aside, I read the page to see if I could find out more
>>>> about the "magic" bug counts that are being aimed for to decide
>when
>>>> to cut the release.  Can someone say what those are and where to
>>>> find them?  I understand from the document that they're not exact
>>>> but even ballpark numbers would be useful.
>>>
>>> OK.
>>>
>>> WRT the bug counts.  0 P1 regressions, < 100 P1-P3 regressions.  I'm
>>> not
>>> sure if that's documented anywhere though.
>>
>> Actually the only criteria is zero P1 regressions.  Those are
>documented to block a release.
>
>Yes, that is mentioned in the document.  Would it be fair to say
>that the number of P2 bugs (or regressions) or their nature plays
>into the decision in some way as well?  If so, what can the release
>criteria say about it?

Ultimatively P2 bugs do not play a role and 'time' will trump them.  OTOH we 
never were in an uncomfortable situation with P2s at the desired point of 
release.

Also note that important P2 bugs can be promoted to P1 and not important P1 to 
P2.

>I'm trying to get a better idea which bugs to work on and where
>my help might have the biggest impact.  I think having better
>visibility into the bug triage process (such as bug priorities
>and how they impact the release schedule) might help others
>focus too.

In order of importance:
- P1
- wrong-code, rejects-valid, ice-on-valid (even if not regressions, regressions 
more important)
- P2 regressions, more recent ones first (newest working version)
 
Richard.

>Martin

Reply via email to