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 <bmbou...@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 <dal...@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 <ipan...@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 <mpusa...@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 <mdell...@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 <ttere...@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@redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> Pulp-dev@redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
