(4) Turning "Backport" to a list of checkboxes with the currently
alive releases.
I missed what the motivation is/was for this proposal?
To avoid typing out (and typoing) release names. Instead, select which
(alive) releases you want to backport the fix to.
Ah! Now I get it. I can see the motivation, but please be aware that
this would break the "backport-create-issue" script.
That script automates the task of scanning issues that have recently
changed to "Pending Backport" status and creates the backport issues
based on the contents of the Backport field, so it's important to make
sure it continues to work. (Not that the script couldn't be modified to
handle the change, of course.)
At some point I would like to move this script into ceph/ceph.git but
that's not a trivial task because it was implemented as part of a larger
framework and will have to be extricated from that, first.
I.e. what is wrong
with the current state? Just that there are EOLed releases in the list?
No, the preseonce of EOL releases in the (proposed) backport checkbox
list would be an issue (as it would be evergrowing and visual
clutter). One option is to delete releases from the checkbox list so
that new (or current) issues cannot select an EOL release but that
also means the release disappears from search in the redmine UI
(although maybe available through manual searches via URL manipulation
or the REST API).
I was thinking about the Release field in the backport tracker, which is
(as you say) "evergrowing" but I'm not sure that's a huge problem given
that we can prune old releases from the list once they have faded into
irrelevance.
BTW this same "evergrowingness" can be observed (and has been "managed")
in e.g. https://github.com/ceph/ceph/blob/master/doc/releases/schedule.rst
Nathan
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
