hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Proposal: Create "branch RM" roles for non releasing branches branch-1, branch-2 (when it exists), and master
Date Sat, 07 Jan 2017 03:15:42 GMT
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