I like this idea in general (and thanks for volunteering!). Speaking specifically about branch-1 and given 2.0 release discussions, is it proper time/thread to also discuss what do we want to do with branch-1? Like, say that 1.4 would be the last release off this line and hence branch-1 should be turned to 1.4, and should we wind down backports to it?
-Mikhail On Fri, Jan 6, 2017 at 5:06 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) > -- Thanks, Michael Antonov
