<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">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>