Re: One month away from GDB 8.0 branching

[Joel Brobecker <brobecker@adacore.com>]

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

-- 
Joel