hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Proposal: Create "branch RM" roles for non releasing branches branch-1, branch-2 (when it exists), and master
Date Sat, 07 Jan 2017 01:06:29 GMT

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

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)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message