Support a given active release branch for 3 years.

[Carlos O'Donell]

On 3/31/20 12:59 PM, Joseph Myers wrote:
> On Tue, 31 Mar 2020, Carlos O'Donell via Libc-alpha wrote:
> 
>> An open glibc release branch will be considered active for 3 years 
>> after the branch opens, at which point the branch is EOL. A 
>> non-active branch is not considered for bug or CVE backports. 
>> This doesn't mean the backports are carried out, that may depend on 
>> resources and interest, but it is considered, for example when 
>> deciding if the bug can be closed. Anyone with commit privileges 
>> can always backport patches from the master branch to any stable 
>> branch, even a closed one, so long as they meet the rules to do so.
> 
> I'm not convinced there's a meaningful distinction being made here between 
> open and closed branches.  Backports might be carried out to closed 
> branches, while it's quite possible no-one is actually interested in 
> carrying out some backport for an open branch, so both kinds of branches 
> might or might not get backports depending on interest.  Bugs are closed 
> when fixed on master, regardless of whether fixed on release branches; the 
> use of list-fixed-bugs.py to list bugs fixed in a new release relies on 
> that.  So there is no distinction regarding whether bugs are closed 
> either.

Let me clarify how I see it then.

Inactive branches:
- Immediately close bugs marked as affecting only closed branch.
- Immediately clear any backport requests for closed branches.
  - Remove keyword glibc_X.Y.
- No security fixes for inactive branches.

Active branches:
- When the branch has a security+ or a CVE identifier we will work
  towards fixing the bug across all active branches.
- When the bug is for an active branch we will review it and consider
  the issue, providing developer guidance, and working on these bugs
  as priority and resources allow.
- Work on requested backports via glibc_X.Y keyword as priority and
  resources allow.

The biggest difference is the CVE backports to the active branches.

There is this recent malloc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=25733

The bug applies to 2.26 and earlier only. DJ has done some triage on
it and we could fix it, but the question is: How far back do we go?
I argued setting security- because almost nobody (very unlikely)
calls mallopt with M_MXFAST and a value between 1-7.

-- 
Cheers,
Carlos.