Re: One month away from GDB 8.0 branching

[Antoine Tremblay <antoine dot tremblay at ericsson dot com>]

Joel Brobecker writes:

>> I'm OK with that however I would like to understand the
>> release/regression process a bit better that's still a bit new to me.
>> 
>> So this means that regressions do not carry over releases ?
>> 
>> So if an issue is introduced like this one from 7.11 to 7.12 and we
>> notice it late, and release 7.12 with it, it's not considered a
>> regression anymore from 7.12 to 8.0 ?
>> 
>> It's just considered a bug ?
>
> No rule is cast in stone. Indeed, the general idea is that,
> if we discover an issue in mast that's not in the latest release,
> these are considered blocking regressions by default. There have
> been cases in the past where we decided to release without the fix,
> and these are decided based on severity, difficulty to fix, expected
> fix date, etc.
>
> For other issues discovered on master, if the issue was introduced
> in a previous release, we tend to classify them as not-blocking
> by default, based on the idea that normally, severe issues tend
> to be discovered quickly, so even if we had missed it for the .0,
> we would have known about it for the .1. Also, if the bug was
> in a release already, doing another release with that bug shouldn't
> hurt (that is, would not make things worse). However, just as before,
> this is only a guideline, and we can review each bug on a case by
> case basis, and with sufficient merit, long-time bugs can still be
> classified as blocking.
>
> I should also add that blocking/non-blocking is just a decision
> process meant to guide the release process. Non-blocking does not
> mean that the next release will necessarily have the bug as well.
> It just indicates that we are not expecting to be waiting for
> those issues to be resolved before we release. Contributing a patch
> ahead of the release process would ensure that the issue gets fixed
> in the release.

Great! thanks for taking the time to clarify that for me :)