We could do it that way but there would be nobody promising to watch branch-1 for any length of time. I'd like to do that. We could do this alternative for branch-2. And it makes sense once we have this sorted to write down what we'd like to do.
> On Jan 9, 2017, at 3:27 PM, Nick Dimiduk <[email protected]> wrote: > > 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) >> >>
