+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 <davidda...@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 <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 >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
