On Thu, 2018-07-26 at 13:59 +0000, Sage Weil 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. > Well, backporting will always be a tradeoff between time spent handling them (the code, the process), and safety/correctness. While 3 relaxes the process by making it simpler, it will also impact the confidence we'll have in them. This will not be a huge problem when dealing with small, trivial backports, but for anything besides that, this can easily come back to bite us. That said, I'm very much in favor of 1/2, although that doesn't mean 3 can't fit in. IMO, a simple process would be something like: 1. everything requires a ticket in the tracker, ideally referencing the original ticket. 2. the checkbox you mentioned, "backport approved" indicates backporting is okay, and should come only after the code has been reviewed by a lead/core maintainer (which likely requires them being asked for review on PRs). 3. anyone is welcome to review backports, and provide their feedback on the tracker ticket; it will be upon the leads to take that into consideration. I think 3. may simplify the leads' life, if we collectively help out ascertaining whether something is valuable, safe, correct. The thing that strikes me as annoying is the checkbox in 2. For it to be feasible, it would likely require multiple tickets, for each release being backported to, for the checkbox to make sense. OTOH, it would make sense to have multiple tickets (one per release) anyway. -Joao -- 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
