From a backporter's perspective, the appealing options are the ones
that reduce the number of stable releases in maintenance at any
particular time.
In the current practice, there are always at least two LTS releases, and
sometimes a non-LTS release as well, that are "live" and supposed to be
getting backports. For example:
* when kraken was released, hammer and jewel were "live LTS" and kraken
was "live non-LTS", for a total of three live releases.
* when luminous was released, hammer and kraken were declared EoL and
there are now only two "live LTS" releases and no "live non-LTS".
During the period when there are three live releases, almost every
bugfix seen as warranting a backport gets marked for backport to the two
most recent stable releases. (For example, from January to August 2017
with very few exceptions tracker issues got marked "Backport: jewel,
kraken", not just "Backport: jewel".) This, of course, doubled the
backporting workload, simply because if a bug is severe enough to
backport to the most recent non-LTS release, it must be severe enough to
be backported to the most recent LTS release as well. Unfortunately,
there aren't enough developers working on backports to cover this double
workload, so in practice the non-LTS release gets insufficient attention.
A "train" model could lower this backporting workload if it was
accompanied by a declaration that the n-1 release gets backports for all
important bugfixes and n-2 gets backports for critical bugfixes only
(and n-3 gets EOLed).
Nathan
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
