Re: [Pulp-dev] Backports and LTS
+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 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 > 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 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 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 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 > 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
Re: [Pulp-dev] Backports and LTS
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 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 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 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 >>> 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 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 advi
Re: [Pulp-dev] Backports and LTS
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 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 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 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 >>> 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 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: > >
Re: [Pulp-dev] Backports and LTS
> > 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 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 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 >> 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 >>> 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. >>
Re: [Pulp-dev] Backports and LTS
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 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 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 >> 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 >>> 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@redha
Re: [Pulp-dev] Backports and LTS
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 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 > 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 >> 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
Re: [Pulp-dev] Backports and LTS
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 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 > 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
Re: [Pulp-dev] Backports and LTS
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 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] Backports and LTS
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
