I agree and I don't have a strong preference between option 1 and 3. If we go with option 1 though, I'd recommend we prioritize automating the rest of our release process. Otherwise, we're going to spend a lot of time releasing.
David 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
