Support a given active release branch for 3 years.

Carlos O'Donell carlos@redhat.com
Thu Mar 26 21:40:58 GMT 2020


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

-- 
Cheers,
Carlos.

[1] https://sourceware.org/glibc/wiki/Release#Distribution_Branch_Mapping
[2] https://sourceware.org/glibc/wiki/Release/#General_policy



More information about the Libc-alpha mailing list