Somewhat late to the reply -- Does it make sense, for branch-1, to have the person planning to RM the next minor release act as the RM for the major-level branch? That person would hand responsibility to the next minor RM upon cutting the stabilization branch.
This could be applied to master/branch-2 as well, but the further away we get from a target release date, the more nebulous the RM role becomes. On Fri, Jan 6, 2017 at 5:07 PM Andrew Purtell <[email protected]> wrote: > HBasers, > > > > I would like to propose extending our informal "branch RM" concept just a > > bit to include the nonreleasing branches like branch-1, branch-2 (when it > > exists), and master. These branches are where all commits are made passing > > through down to the releasing branches targeted for the change (like, > > branch-1.1, branch-1.2, branch-1.3, etc.) > > > > The releasing branches all have their own RM. I assume that RM is > > diligently monitoring its state, by way of review of commit history, > > occasional execution of the unit test suite, occasional execution of the > > integration tests, and has perhaps some automation in place to help with > > that on a nightly or weekly basis. No matter, let's assume there is a > > nonzero level of scrutiny applied to them, which leads to feedback to > > committers about inappropriate commits via compat guidelines, commits which > > have broken unit tests, or other indications of quality or functional > > concerns. I think it would improve our overall velocity as a project if we > > could also have volunteers tending the development branches upstream from > > the releasing branches. Less work would fall to the RMs tending the release > > branches if a common troublesome commit can be caught upstream first. In > > particular I am thinking about branch-1. > > > > I would like to volunteer to become the new RM for branch-1, to test and > > refine my above proposal in practice. Unless I hear objections I will > > assume by lazy consensus everyone is ok with this experiment. > > > > What this would mean: > > > > - JIRAs like "TestFooBar is broken on branch-1" will show up sooner, and > > more likely with fix patches > > - Semiregular performance reports on branch-1 code as of date X/Y/Z, can > > compare with earlier reports for trending > > - Occasional sweep through master history looking for appropriate > > candidates for backport to branch-1, execution of said backport > > - Occasional 1B row ITBLL torture tests, probably if failure with bisect > > back to commit that introduced instability > > > > What this does not mean: > > > > - The branch-1 RM will not attempt to tell other branch RMs what or what > > not to include in their release branches > > - The branch-1 RM won't commit anything backported from master to any of > > the release branches; it will continue to be up to the release branch > RMs > > what they would or would not like to be included > > > > Also, I don't see why I couldn't spend some time looking at master now and > > then. > > > > I am going to assume our current co-RM team for branch-2 would maybe do > > something similar for branch-2, once it materializes. > > > > Thoughts? Comments? Concerns? > > > > > > > > > > -- > > Best regards, > > > > - Andy > > > > If you are given a choice, you believe you have acted freely. - Raymond > > Teller (via Peter Watts) > >
