[Pulp-dev] Backports and LTS

David Davis daviddavis at redhat.com
Wed Jan 6 14:38:09 UTC 2021

I agree and I don't have a strong preference between option 1 and 3. If we
go with option 1 though, I'd recommend we prioritize automating the rest of
our release process. Otherwise, we're going to spend a lot of time


On Wed, Jan 6, 2021 at 8:58 AM Ina Panova <ipanova at redhat.com> wrote:

> Matt, that is a good observation and meanwhile with pulp2 we had such a
> policy, we cannot adopt it with pulp3. Release fast and release often is
> something we are trying to stick to.
> It would be best to agree on the LTS version that would make all the
> stakeholders happy but as it was pointed out not sure how we'd make this
> possible, everyone has a different pace and release cycle.
> Having that said, we should probably stick to option1 which puts more
> burden on us but in return users and stakeholders are happy and the
> project's upgrade path is stable.
> One thing we could possibly do about the backport requests is to really be
> thorough about which ones to accept by assessing the impact of the
> stakeholder who has created the request and their possibility to upgrade if
> any.
> --------
> Regards,
> Ina Panova
> Senior Software Engineer| Pulp| Red Hat Inc.
> "Do not go where the path may lead,
>  go instead where there is no path and leave a trail."
> On Wed, Jan 6, 2021 at 2:18 PM Matt Pusateri <mpusater at redhat.com> wrote:
>> Another option is Current Version minus X (N-1, N-2, etc.) If for
>> instance you say we support N-1, and current version is 3.9, then you'll
>> back port to latest 3.8.x.  N-2 at current version 3.9, would backport to
>> 3.8.x, 3.7.x, etc.  The advantages here are that you already set the
>> expectation for everyone, you limit the versions you support, you force
>> people to stay current to get fixes.  The downside is that people have to
>> upgrade and or it could impact downstream schedules.  The impact with going
>> this route is affected by the release velocity.  So if you're rapidly
>> releasing major versions, then it's more likely people won't keep up, or
>> that they'll have to upgrade and are not able to for some reason.
>> Matt P.
>> On Wed, Jan 6, 2021 at 6:05 AM Matthias Dellweg <mdellweg at redhat.com>
>> wrote:
>>> Thanks for putting all the options together.
>>> I would say that option 2 is a recipe for very bad user experience, and
>>> i'd vote strongly against it.
>>> I am ok with option 1, but I would add that the backport to the
>>> intermediate minor releases _must_ be performed (as in released) counting
>>> down, to always meet that upgrade expectation. Remember releasing can be
>>> delayed unexpectedly due to reasons.
>>> If we go for option 3, I think it's advisable to try to sync up
>>> stakeholders, because we don't want to maintain consecutive minor versions
>>> as LTS, and again, backporting a fix must traverse all maintained LTS in
>>> backward order. We should add expectations to how long we can keep an LTS
>>> version alive, and how often we bless one.
>>> On Tue, Jan 5, 2021 at 6:34 PM Tanya Tereshchenko <ttereshc at redhat.com>
>>> wrote:
>>>> With more and further away backport requests coming in, there is more
>>>> need for a clear policy/docs to set expectations for users and to define
>>>> requirements for those performing a backport.
>>>> The question which hasn't been answered yet (in documented way) is:
>>>> *Should backports be backported to every (minor) version between the
>>>> fix and the requested version?*
>>>> E.g. A backport is requested for 3.7, the original fixed will be
>>>> released in 3.10.
>>>> Should the backport be added only to 3.7 or to 3.8 and 3.9 as well?
>>>> Reminder: a backport can only be a bug fix and without a db migration.
>>>> Option 1. Backport to all releases in between.
>>>>  + it's an expected upgrade path for users, no surprises, the fix is
>>>> present all the way.
>>>>  - it's a lot of maintenance and release burden, and the further
>>>> backport is the worse it is.
>>>> Option 2. Backport to the requested release only.
>>>>  + just one backport and release to do
>>>>  - inconsistent user experience if a user doesn't upgrade to the latest
>>>> version. E.g. a fix from 3.10 is backported to 3.7 only. If a user upgrades
>>>> to 3.8 or 3.9. they will no longer have a fix. It's very unexpected at the
>>>> very least, imo.
>>>> Option 3. Have LTS releases and allow backports to the latest LTS only
>>>>  + just one backport and release to do
>>>>  + users are aware that backports go only into this release and do not
>>>> expect fixes in non-LTS releases in between
>>>>  - less flexibility with multiple stakeholders (e.g. Katello will
>>>> benefit from 3.7 being an LTS release, Galaxy - from 3.8)
>>>> Please share your thoughts or suggest other options,
>>>> Tanya
>>>> _______________________________________________
>>>> Pulp-dev mailing list
>>>> Pulp-dev at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20210106/d6d79374/attachment.htm>

More information about the Pulp-dev mailing list