<oooOOOOooooo thread necro!> Did we ever actually make any of these changes, or merely agree that there ought to be more of an explicit approval step and then lose it to people going on vacation? :) -Greg On Sun, Jul 29, 2018 at 11:25 AM, Nathan Cutler <ncutler@xxxxxxx> wrote: >> 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
