hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikhail Antonov <olorinb...@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 21:39:07 GMT
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

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