Re: Debian support lifetime (was Re: [PATCH] docker: move tests from python2 to python3)

[John Snow]

On 9/26/19 7:58 AM, Daniel P. Berrangé wrote:
> On Wed, Sep 25, 2019 at 05:04:40PM -0300, Eduardo Habkost wrote:
>> On Tue, Sep 24, 2019 at 08:35:13AM +0100, Daniel P. Berrangé wrote:
>>> On Mon, Sep 23, 2019 at 04:05:33PM -0300, Eduardo Habkost wrote:
>> [...]
>>>> Even for other long-lifetime distros, I really think "2 years
>>>> after the new major version is released" is too long, and I'd
>>>> like to shorten this to 1 year.
>>>
>>> I guess this is ok, since this. is still quite a long life time of
>>> support for distros. eg RHEL has a 3-4 year gap between major
>>> releases, that gives 4-5 years for each release being supported by
>>> QEMU. Other LTS distros are similar
>>
>> Do you mean the 2 years period is OK (and shouldn't be changed),
>> or that shortening it to 1 year is OK?
> 
> When first wording the lifetimes, I tried to strike a balance between
> limiting what we have to support, while also not negatively impacting
> a large number of QEMU developers or users. Since we had never had
> such support lifetimes declared for QEMU before, I was fairly generous,
> hence picking the 2 year overlap for LTS distros (Ubuntu, RHEL and
> SLES).
> 
> It is easier to come to a decision when considering a real world tech
> problem related to the lifetime. 
> 
> The start of this thread was debating Debian / Python support. If we
> fix the doc to put debian under the short life distro category, we'll
> have solved the Python problem IIUC.
> 

As I laid out in an earlier reply -- that's one solution. It seems to
cover our current cases adequately.

The other, equally viable solution, is not to consider an artificial
divide between long and short cycle distros, and simply say "Releases
are supported for two years after the following major release, or until
EOL, whichever comes first."

This gives us the same end effect, but is simpler to follow, easy to
understand, and avoids classification difficulties.

$0.02

> Then I'd suggest we just leave LTS distros as a 2 year overlap until
> we hit some technical problem that is caused by needing the 2 year
> overlap. That way we can consider the cost/benefit in more real terms.
> 
> 
> Regards,
> Daniel
>