Support a given active release branch for 3 years.

[Carlos O'Donell]

On 3/26/20 5:40 PM, Carlos O'Donell wrote:
> Now that I have some long-term empirical data on releases [1]
> and their general consumption, it looks like a 3 year open-branch
> policy works to cover the current releases of Fedora, Ubuntu, and
> Debian (which cover the range of fast adoption to slower adoption).
> This would cover the last 6 releases.
> 
> We would need an almost 6 year open-branch policy to cover Debian's
> LTS, and I don't want to commit to reviewing CVEs and other critical
> bug fixes for branches that old. Likewise for Ubuntu's LTS. However,
> I have no objection to anyone with commit privileges committing to
> older branches.
> 
> It also lines up closely with what I'm suggesting in this thread:
> https://sourceware.org/pipermail/libc-alpha/2020-March/112195.html
> glibc 2.25 was released on 2017-02-01 which means under this policy
> it would close on 2020-02-01 (two months ago).
> 
> In summary:
> 
> - 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 [2].
> 

Any feedback on this policy?

Suggested text to be added to wiki Release #GeneralPolicy:
~~~
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.
~~~

It would mean that today we would be supporting the following branches:

release/2.26/master EOL on 2020-08-02
release/2.27/master EOL on 2021-02-01
release/2.28/master EOL on 2021-08-01
release/2.29/master EOL on 2022-02-01
release/2.30/master EOL on 2022-08-01
release/2.31/master EOL on 2023-02-01 

When 2.32 releases on 2020-08-02 we EOL 2.26, so we always have 6 active
branches, and drop one out every 6 months.

I would update the glibc timeline here to reflect EOL dates:
https://sourceware.org/glibc/wiki/Glibc%20Timeline

Updated version for review:
https://sourceware.org/glibc/wiki/Glibc Timeline v2

I would make it clear that while the community EOLs the release, that
distributions may choose to actively maintain the branch on their own.

-- 
Cheers,
Carlos.