[Pulp-dev] Backports and LTS

Tue Jan 12 20:47:20 UTC 2021

Stakeholder's won't agree on a single "LTS" (agreed daniel that's not a
great name for it) so I think option 3 is a non-starter. Option 2 is what
we do today and I agree it has the issues already mentioned.

So +1 to option 1, but as already mentioned, practically speaking, I
believe we can't release any more than we are without fully automating the
process. Can we fully automate the release process first, and then
re-discuss a policy change after?

On Wed, Jan 6, 2021 at 12:12 PM Daniel Alley <dalley 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.
>>
>
> I don't think Matt was suggesting in any way that we not release fast and
> often, it's just that we have to pick a combination of cadance and # of
> supported releases that works for everyone.  This is basically Option 1
> with a pre-determined number of supported releases (rather than "backport
> to whatever version the stakeholder is using + all the others in between"
> which is how I interpret Option 1).
>
> I totally agree with David that it would be a pain to manage without
> automation though, same as Option 1.
>
> I think what would most likely happen under that plan is that we would see
> each stakeholder will take a release, stick to it until it is about to be
> dropped and then upgrade to the newest one, which is roughly the same as
> the LTS plan except that each stakeholder can choose their own "LTS"
> version and they could do an mid-cycle upgrade if there was ever a good
> reason to.
>
> Whatever option we choose, I'm kind of negative about actually using the
> term "LTS" given that I don't think we'd be supporting any version for more
> than 5-7 months.  The timeframe is a bit short for how the LTS moniker is
> typically used.
>
> 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
>>
> _______________________________________________
> 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/20210112/4e4c456a/attachment.htm>