I was thinking in similar lines that the RM for 1.X which is the next one
would be managing branch-1, but I am also concerned about the large gap in
terms of timing. For example, unless we are close to 1.4, an 1.4 RM will
not materialize.

So, I am in favor of having an informal branch-1 RM that will work with the
1.x RMs. An +1 for Andrew for that role.

Enis

On Wed, Jan 11, 2017 at 1:17 PM, Andrew Purtell <[email protected]>
wrote:

> 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)
> >>
> >>
>

Reply via email to