<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>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.</div></div></blockquote><div><br></div><div>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).<br></div><div><br></div><div>I totally agree with David that it would be a pain to manage without automation though, same as Option 1.</div><div><div><br></div><div> 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.</div></div><div><br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 6, 2021 at 8:58 AM Ina Panova <<a href="mailto:ipanova@redhat.com">ipanova@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div>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.</div><div>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.<br></div>--------<br><div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr">Regards,<br><br>Ina Panova<br>Senior Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 6, 2021 at 2:18 PM Matt Pusateri <<a href="mailto:mpusater@redhat.com" target="_blank">mpusater@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div><div><div dir="ltr"><div dir="ltr">Matt P. <br></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 6, 2021 at 6:05 AM Matthias Dellweg <<a href="mailto:mdellweg@redhat.com" target="_blank">mdellweg@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks for putting all the options together.</div><div>I would say that option 2 is a recipe for very bad user experience, and i'd vote strongly against it.</div><div>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.</div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 5, 2021 at 6:34 PM Tanya Tereshchenko <<a href="mailto:ttereshc@redhat.com" target="_blank">ttereshc@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>The question which hasn't been answered yet (in documented way) is:</div><div><i>Should backports be backported to every (minor) version between the fix and the requested version?<br></i><div><br></div></div><div>E.g. A backport is requested for 3.7, the original fixed will be released in 3.10.</div><div>Should the backport be added only to 3.7 or to 3.8 and 3.9 as well?</div><div>Reminder: a backport can only be a bug fix and without a db migration.</div><div><br></div><div>Option 1. Backport to all releases in between.</div><div> + it's an expected upgrade path for users, no surprises, the fix is present all the way.</div><div> - it's a lot of maintenance and release burden, and the further backport is the worse it is.</div><div><br></div><div>Option 2. Backport to the requested release only.</div><div> + just one backport and release to do</div><div> - 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.</div><div><br></div><div>Option 3. Have LTS releases and allow backports to the latest LTS only</div><div> + just one backport and release to do</div><div> + users are aware that backports go only into this release and do not expect fixes in non-LTS releases in between</div><div> - less flexibility with multiple stakeholders (e.g. Katello will benefit from 3.7 being an LTS release, Galaxy - from 3.8)</div><div><br></div><div>Please share your thoughts or suggest other options,<br></div><div>Tanya</div></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>