hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@gmail.com>
Subject Re: Proposal: Create "branch RM" roles for non releasing branches branch-1, branch-2 (when it exists), and master
Date Mon, 09 Jan 2017 23:27:43 GMT
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 <apurtell@apache.org> 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)
>
>

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