These tend to make the process harder/slower but don't really get at the
part where someone says "should we be doing this?". Two process-y options
come to mind:
1- In the 'Pending backport' state, the backport bugs get a 'Pending
approval' state. Or, 'pending backport approval' come sbefore 'pending
backport'. Or, a new 'backport approved' checkbox field for backports.
As long as it's something that we can build a redmine query for. And the
team lead or a core maintainer has to say yes or no before the
backporting work begins.
2- Once the backport PR is opened, a review is always requested
from the lead.
Or,
3- We collectively pay more attention to the reviews for backports and
consider whether the backport is really a good idea and worth the risk.
I kind of like 1, but 3 is certainly the simplest.
I like (1) - how about this as a clarification:
Turn the existing "Backport" field into "Backport requested".
Add two new checkboxes: "Backport approved (S)" and "Backport approved
(S-1)" - S is short for "the most recent stable release" and S-1 means
"the second-most recent stable release".
Crucially, the two new "Backport approved" boxes would require
administrator privileges to "tick" (for Britons) or "check" (for Americans).
The script src/script/backport-create-issue would be adapted so it
creates issues only for approved backports.
Somewhere there would need to be a mapping which would be updated when a
new stable release comes out. At the moment it would be:
S -> mimic
S-1 -> luminous
What do you think?
(BTW, I like your idea for the backporter to be required to do "git log
--grep" on all the master SHA1s to check for follow-on fixes.)
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
