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
