[Pulp-dev] Backports and LTS

Tue Jan 12 21:10:41 UTC 2021

There are some great features that have been added to Github Actions--one
of them being manual triggers for workflows (before we weren't sure how we
could trigger the entire release process). So I think we're in a good
position now that we're on Github Actions to automate the rest of the
release process.

The problem is finding the time. I think we're all spread thin and we're
talking about a week or two...? I would love to see this happen though as I
think it would pay for itself after a couple releases.

David

On Tue, Jan 12, 2021 at 3:48 PM Brian Bouterse <bmbouter at redhat.com> wrote:

> 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
>>
> _______________________________________________
> 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/e6f4e0e2/attachment.htm>