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: <CAN5cbe742oK3=ewSZBAHwHTgNWnSt2bGrZhB7nGcz7rU3DkwYA@mail.gmail.com>
References: <CADcMMgGxVS3YxyUk8MK5UtwjC=rBGrD8djqiRHFpmTZM3fhOmA@mail.gmail.com>
 <CAN5cbe742oK3=ewSZBAHwHTgNWnSt2bGrZhB7nGcz7rU3DkwYA@mail.gmail.com>
From: Mikhail Antonov <olorinbant@gmail.com>
Date: Tue, 8 Aug 2017 08:10:12 -0700
Message-ID: <CAHxLZBWzVOEqCVek8MeMc9kd4xNRrLhAfea5OXYbEr_euVOw6Q@mail.gmail.com>
Subject: Re: DISCUSS: How can we have less branches?
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary="001a113eeb18f9ebca05563f5db0"
archived-at: Tue, 08 Aug 2017 15:10:48 -0000

--001a113eeb18f9ebca05563f5db0
Content-Type: text/plain; charset="UTF-8"

I think in the dev community interest and ultimately in interest of our
users to have a fewer maintained branches.

For a variety of reasons.

Efforts put in the maintenance of old release lines is the effort not put
into releasing new ones, since community resources are
finite. Active backporting (beyond critical security fixes and such) of new
things somewhat reduces users incentive to upgrade often. Then we can get
in the loop situation when new major features aren't deemed very stable -
but it's really hard to get features of that complexity stable and robust
if they're not used beyond integration tests.

So before we go too deeply into discussion on how to make backporting
easier, I'd rather see us focusing on releasing new branches and making
them stable.

-Mikhail


On Tue, Aug 8, 2017 at 7:10 AM, Sean Busbey <busbey@apache.org> wrote:

> Are we approaching this problem wrong though?
>
> Most of the cherry picks I have to do to the maintenance release lines are
> clean.
>
> What if we get more tooling to help with the everything-goes-right case?
>
> My last read of asf policy and infra folks (from back in the website
> automation) is they won't look favorably on Jenkins pushing back ports into
> our repo.
>
> But! We could make something similar to the website job from back when a
> committer still had to do the git push. A nightly job that tries to cherry
> pick and gives us a set of back ports that worked.
>
> We could either have it look to jira for fix versions to try backporting
> to, or we could have it try everything and update jira with what worked.
>
> Thoughts?
>
> On Aug 8, 2017 02:14, "Stack" <stack@duboce.net> wrote:
>
> > (This came up during dev meeting in Shenzhen) We are running too many
> > branches and/or when applying patches, we do not do a good job
> backporting
> > to all active branches, especially fixes.
> >
> > We have master, branch-2, branch-1, branch-1.4, branch-1.3, branch-1.2,
> and
> > branch-1.1 active currently. If a dirty bug fix, the applier is
> backporting
> > to 7 branches. It takes a while applying to all especially if the
> backport
> > doesn't go in clean. I suppose the RM could monitor all upstream of them
> > and then pull wanted patches back (we could do that too) but seems like a
> > burden on an RMer.
> >
> > We should EOL a few?
> >
> > Nick is on branch-1.1 release at the moment. Perhaps this could be the
> last
> > off branch-1.1.
> >
> > 1.2 hosts our current stable release though 1.3 is out. How about we cut
> a
> > release off 1.3, call it stable, and then EOL 1.2 after another release
> or
> > so?
> >
> > What you all think?
> >
> > Thanks,
> > S
> >
>


-- 
Thanks,
Michael Antonov

--001a113eeb18f9ebca05563f5db0--