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: <CAHxLZBU75KjEwAswKpLske01GgKx6WcuwURRGRWU3qZTMjSQ3A@mail.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> <CAN5cbe7d5NZz0HKOTGddSnSAq2rHnxsVqTEb9QMnQf6RNedwCQ@mail.gmail.com>
 <CAHxLZBWtw_3+jGcEVz80KdCD_hgJpeDE0Kb1QffqWP7m=C9C2w@mail.gmail.com>
 <CA+RK=_By+67cCmOQQb5uetLXyy8Pzuuugpm81GH4=FTyFUjPRQ@mail.gmail.com> <CAHxLZBU75KjEwAswKpLske01GgKx6WcuwURRGRWU3qZTMjSQ3A@mail.gmail.com>
From: Andrew Purtell <apurtell@apache.org>
Date: Mon, 9 Jan 2017 13:50:45 -0800
Message-ID: <CA+RK=_Au9+NeD7Qv_b_fn_5ovWqxSHw4=okcN0KTVm8tKbXcFQ@mail.gmail.com>
Subject: Re: Proposal: Create "branch RM" roles for non releasing branches
 branch-1, branch-2 (when it exists), and master
To: "private@hbase.apache.org" <private@hbase.apache.org>
Cc: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=f403045ea1088d7be40545b05e83
archived-at: Mon, 09 Jan 2017 21:51:31 -0000

--f403045ea1088d7be40545b05e83
Content-Type: text/plain; charset=UTF-8

As branch-1 "RM" I don't need to be in the loop when a committer wants to
commit something there, and wouldn't have the bandwidth for it anyway. So
if someone wants to put something in branch-N.M, feel free to commit it to
master, then branch-N, then branch-N.M, as is our current workflow. If the
commit is bad and not dealt with in a timely manner it may be reverted from
both places (potentially by me). This is also not a change, except someone
is paying more attention to branch-1. I also agree that if we've reverted
something from branch-N then it has to be reverted from branch-N.M, and I
would expect the PMC to enforce this sanity. Likewise, if something has
been released on branch-N.M, then it cannot be reverted from branch-N. That
kind of inconsistency in commit lineage would make things unmanageable.

Th most likely case where the branch-N maintainer's judgement would come in
conflict with a committer's judgement and need resolution would be if a
commit is made that causes observed instability, or performance regression,
or is a (potentially, debatable) violation of compatibility guidelines, and
the branch-N maintainer executes a revert of the commit from branch-N and
any children branch-N.M, so long as the change has not been released.


On Mon, Jan 9, 2017 at 1:39 PM, Mikhail Antonov <olorinbant@gmail.com>
wrote:

> One question to reiterate on the commit flow..
>
> I think we agreed, as you said, that branch-N RM won't dictate what to
> backport and what not to released branches maintainers, but
> at least logically I'd still treat that as an additional "line of defense"
> for too big, too risky or otherwise questionable commits. I.e. if branch-N
> RM
> doesn't feel like porting patch from master to branch-N, it's surely isn't
> safe enough to port to branch-N.M? Thoughts?
>
> -Mikhail
>
> On Mon, Jan 9, 2017 at 12:43 PM, Andrew Purtell <apurtell@apache.org>
> wrote:
>
> > Good, I think we are on the same page regards a long term maintainer for
> > branch-1. I can make a multi year commitment like I did with 0.98. How
> that
> > works with respect to branching for minor releases we can figure out. My
> > thought is anytime someone wants to branch off to make a minor release,
> RM
> > it, and run with it, that's great, and the more on the project who do
> that
> > the better off we will be with the releasing work well spread around. At
> > the same time people won't have infinite time to maintain minor branches
> > and generate patch releases, so when the maintainer of a minor branch
> feels
> > like moving on, whenever that is, this is perfectly fine. This is
> basically
> > the current situation, except maybe minor branch RMs are feeling they
> have
> > themselves taken on a long term commitment (this can change, up to the
> > individual, as it has always been), and there is no maintainer on the
> > upstream branch (this will change).
> >
> >
> > On Mon, Jan 9, 2017 at 10:35 AM, Mikhail Antonov <olorinbant@gmail.com>
> > wrote:
> >
> > > I should say I was talking more about "should these things be discussed
> > > together or separately", not any particular direction we should
> > > or should not take, as I didn't want to accidentally steal the topic.
> > >
> > > But speaking specifically on that.. saying that we're going to maintain
> > > branch-1 lines until at least Feb 2018 definitely makes total sense to
> > me.
> > > 2 years overlap with 2.0 might be something we'd want to discuss in
> some
> > > more depth.
> > >
> > > -Mikhail
> > >
> > > On Mon, Jan 9, 2017 at 10:26 AM, Sean Busbey <busbey@apache.org>
> wrote:
> > >
> > > > On Fri, Jan 6, 2017 at 7:43 PM, Mikhail Antonov <
> olorinbant@gmail.com>
> > > > wrote:
> > > > > ...
> > > > >
> > > > > 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?
> > > >
> > > > On Fri, Jan 6, 2017 at 8: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).
> > > > >
> > > > > ...
> > > >
> > > > I would definitely not be comfortable retiring branch-1 any time this
> > > > CY, given the unknown state of both the 2.0 release process and how
> > > > long that branch has been without a release. Three years from 1.0.0
> > > > puts us at February 2018. The 0.98 branch had the benefit of nearly 2
> > > > years overlap with branch-1 releases; should branch-1 have a similar
> > > > window with branch-2?
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks,
> > > Michael Antonov
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > If you are given a choice, you believe you have acted freely. - Raymond
> > Teller (via Peter Watts)
> >
>
>
>
> --
> Thanks,
> Michael Antonov
>


-- 
Best regards,

   - Andy

If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)

--f403045ea1088d7be40545b05e83--