[Pulp-dev] Backports and LTS

Wed Jan 13 13:51:23 UTC 2021

+1 to fully automating the release pipeline. This would allow us to do as
many releases as needed to satisfy all stakeholders.

On Tue, Jan 12, 2021 at 4:11 PM David Davis <daviddavis at redhat.com> wrote:

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