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