Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
MIME-Version: 1.0
In-Reply-To: <9BE2D384-77EB-4C38-BA59-C623E94AB4B2@gmail.com>
References: <CA+RK=_BGQkZfv_CfMrPtbVLXcnZPC_RD4pgWCEVnrF7QKpR_YA@mail.gmail.com>
 <CAHxLZBVfy5JXWbM6kTisJZ9+W6e596YJ2HeGF2a0-tYYd8WRGw@mail.gmail.com> <9BE2D384-77EB-4C38-BA59-C623E94AB4B2@gmail.com>
From: Ted Yu <yuzhihong@gmail.com>
Date: Fri, 6 Jan 2017 19:15:42 -0800
Message-ID: <CALte62xS+phxfcWfQu4K6D6wSbPUPohnHtquowe68Te7TeMSbw@mail.gmail.com>
Subject: Re: Proposal: Create "branch RM" roles for non releasing branches
 branch-1, branch-2 (when it exists), and master
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Cc: "private@hbase.apache.org" <private@hbase.apache.org>
Content-Type: multipart/alternative; boundary=94eb2c084140bed9fe0545788c61
archived-at: Sat, 07 Jan 2017 03:15:49 -0000

--94eb2c084140bed9fe0545788c61
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 b=
ug
> 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 poin=
t
> 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 jus=
t
> 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 t=
he
> >> integration tests, and has perhaps some automation in place to help wi=
th
> >> 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 a=
nd
> >> 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 an=
y
> of
> >>   the release branches; it will continue to be up to the release branc=
h
> >> RMs
> >>   what they would or would not like to be included
> >>
> >> =E2=80=8BAlso, I don't see why I couldn't spend some time looking at m=
aster now
> and
> >> then.
> >>
> >> I am going to assume our current co-RM team for branch-2 would maybe d=
o
> >> something similar for branch-2, once it materializes.
> >>
> >> Thoughts? Comments? Concerns?
> >> =E2=80=8B
> >>
> >>
> >>
> >> --
> >> Best regards,
> >>
> >>   - Andy
> >>
> >> If you are given a choice, you believe you have acted freely. - Raymon=
d
> >> Teller (via Peter Watts)
> >>
> >
> >
> >
> > --
> > Thanks,
> > Michael Antonov
>

--94eb2c084140bed9fe0545788c61--