[prev in list] [next in list] [prev in thread] [next in thread] 

List:       glibc-alpha
Subject:    Re: Support a given active release branch for 3 years.
From:       Carlos O'Donell via Libc-alpha <libc-alpha () sourceware ! org>
Date:       2020-03-31 17:29:20
Message-ID: 1d8fb276-bce2-41ee-8468-9f6c9ce421eb () redhat ! com
[Download RAW message or body]

On 3/31/20 1:24 PM, Florian Weimer wrote:
> * Joseph Myers:
> 
>> 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.
> 
> I also don't see a meaningful difference.
> 
> It would matter if we cut releases from the branches, or published
> security advisories analyzing the impact for each vulnerability.  But
> we currently do neither.  So I don't think the distinction matters in
> practice.

We just went through a backport sequence for CVE-2020-1751,
CVE-2020-1752, and CVE-2020-10029.

We did that because they mattered to us downstream in Fedora.

For a little more effort we could have covered the "active" set of
branches upstream if we had such a distinction.

Without the distinction neither Fedora nor any other distribution
can help us meet those guidelines.

Does that help clarify why we might want to make the distinction?

-- 
Cheers,
Carlos

[prev in list] [next in list] [prev in thread] [next in thread]