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: <CADcMMgGxVS3YxyUk8MK5UtwjC=rBGrD8djqiRHFpmTZM3fhOmA@mail.gmail.com>
References: <CADcMMgGxVS3YxyUk8MK5UtwjC=rBGrD8djqiRHFpmTZM3fhOmA@mail.gmail.com>
From: Sean Busbey <busbey@apache.org>
Date: Tue, 8 Aug 2017 09:10:51 -0500
Message-ID: <CAN5cbe742oK3=ewSZBAHwHTgNWnSt2bGrZhB7nGcz7rU3DkwYA@mail.gmail.com>
Subject: Re: DISCUSS: How can we have less branches?
To: dev <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary="001a113f909ae6c10c05563e875a"
archived-at: Tue, 08 Aug 2017 14:10:56 -0000

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

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
>

--001a113f909ae6c10c05563e875a--