[Pulp-dev] Backports and LTS

[Matthias Dellweg]

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 <ttereshc at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20210106/96fbacc4/attachment.htm>