hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Yang <ud1...@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 08:01:08 GMT
Like this idea. I think it will help us making non-releasing branches more
stable, and reduce delay from cutting releasing branch to release first
x.y.0 version which means users will meet new features earlier :)

And I have two questions :)

> Occasional sweep through master history looking for appropriate candidates
for backport to branch-1, execution of said backport

Now the authors of every issues backport new features to branch-1 after
they have a patch for master, and committers help them push patches to git.
So usually master and branch-1 introduce two patches for a issue at time
same time. If we have branch RMs, who should make a decision that if we
need to backport a new feature to branch-x? And when we do the backport
work?

If we have branch-RMs helping us make non-releasing branches more stable,
we may be able to cutting new releasing branch more regular? Do we have a
plan that how often we cut a new releasing branch?

Thanks,
Phil


2017-01-07 11:15 GMT+08:00 Ted Yu <yuzhihong@gmail.com>:

> bq. to see branch-1 be our new long term stable branch
>
> I agree.
> Having an experienced PMC shepherding branch-1 would lay good foundation
> for future 1.4+ and 2.x releases.
>
> +1 with Andrew taking up this role.
>
> Cheers
>
> On Fri, Jan 6, 2017 at 6:07 PM, Andrew Purtell <andrew.purtell@gmail.com>
> wrote:
>
> > I would like to see branch-1 be our new long term stable branch and so to
> > be maintained for roughly as long as 0.98 was: three years from first
> > release (1.0.0).
> >
> > It would be maintained the same way as 0.98 was. I would like to drive
> > monthly releases but they would only be -SNAPSHOT and never advertised as
> > an official release. So to get actual shipping code I guess I'd have to
> bug
> > the release RMs (smile).
> >
> > If the branch-1 RM felt like sweeping up changes and backporting for as
> > long as he/she likes that would be fine with me. If I were branch-1 RM I
> > would do that on a monthly basis. Only changes allowable on minor or
> point
> > revisions according to our compatibility guidelines would be allowed.
> >
> > We don't have a release branch RM for 1.4. I would be happy to take on
> > that role too, but I think it premature given 1.3.0 isn't even out yet.
> >
> >
> > > On Jan 6, 2017, at 5:43 PM, Mikhail Antonov <olorinbant@gmail.com>
> > wrote:
> > >
> > > 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 <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)
> > >>
> > >
> > >
> > >
> > > --
> > > Thanks,
> > > Michael Antonov
> >
>

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