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: <CAN+qs_Mme9Q=4yQRcXfCvH0M28R_2sYyFc4cZY6Ty1jMQTEe3A@mail.gmail.com>
References: <CADcMMgGxVS3YxyUk8MK5UtwjC=rBGrD8djqiRHFpmTZM3fhOmA@mail.gmail.com>
 <CANZa=Gs4ZGxJNQQ3r-fMC968WNeLNHoYtsjzKhs3QNO-O_9Ydg@mail.gmail.com>
 <CAFAMeYLnxhoW2niSvWHR7QibtNJMAqCY2CrT-VudyaHf+N7o9A@mail.gmail.com>
 <CANZa=GujbivcPMufRKcHGN5TF7SA+OSsZEgN_zBP9XF80s1hqA@mail.gmail.com>
 <CA+RK=_CwH+-2xcQaowJyZ4+gy5AzJdLu3PGnm2atRQ3W4yaqMA@mail.gmail.com> <CAN+qs_Mme9Q=4yQRcXfCvH0M28R_2sYyFc4cZY6Ty1jMQTEe3A@mail.gmail.com>
From: Andrew Purtell <apurtell@apache.org>
Date: Tue, 8 Aug 2017 10:44:33 -0700
Message-ID: <CA+RK=_BhJ+EHmp80h=DT1Ue=_X+NZR57cLqYh7zEA3sbz8=cKg@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="001a113df2188a0ffd05564186c2"
archived-at: Tue, 08 Aug 2017 17:45:18 -0000

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

Well you are not wrong that branching was premature, it turns out. But I'll
roll with it...


On Tue, Aug 8, 2017 at 10:43 AM, Zach York <zyork.contribution@gmail.com>
wrote:

> > I made branch-1.4 a few weeks ago only.
>
> Whoops, sorry for that! For some reason I thought I had seen it months ago.
>
> On Tue, Aug 8, 2017 at 10:40 AM, Andrew Purtell <apurtell@apache.org>
> wrote:
>
> > +1 from me on making 1.1 our LTS. Either 1.1 or 1.2 are candidates. I
> think
> > 1.1 has the edge because it lacks locking changes introduced into 1.2,
> just
> > like 1.2 lacks locking changes introduced in 1.3 - the latter of which
> has
> > had far reaching consequences, and the former not an insignificant change
> > either.
> >
> >
> >
> > On Tue, Aug 8, 2017 at 10:31 AM, Nick Dimiduk <ndimiduk@gmail.com>
> wrote:
> >
> > > On Tue, Aug 8, 2017 at 9:15 AM Mike Drob <mdrob@apache.org> wrote:
> > >
> > > > > The discussion also brought up the notion of an LTS release line.
> I'm
> > > not
> > > > > sure how this jives with the more fequent minors, but would require
> > > some
> > > > > branch that's so stable that an RM can effectively spin releases
> > blind.
> > > >
> > > > Seems to me like this branch would necessarily need to be very
> > > > backport-light? Only the top of the highest priority issues would be
> > > > backportable to it, no?
> > >
> > >
> > > The LTS is as 1.1 is today -- bug fixes only. The difference here is
> we'd
> > > "formally" recognize the LTS designation somehow, perhaps with a
> symlink
> > > marker as we do for the "stable" designation.
> > >
> > > On Tue, Aug 8, 2017 at 11:09 AM, Nick Dimiduk <ndimiduk@apache.org>
> > wrote:
> > > >
> > > > > Last time we DISCUSSed EOL of 1.1 was back in November. At that
> > time, a
> > > > > litany of issues were raised re: 1.2. Have those concerns been
> > > addressed?
> > > > > It seems to me that making this one the last release is too abrupt
> to
> > > > folks
> > > > > tracking Apache. Would be better to give some notice.
> > > > >
> > > > > Had a nice hallway conversation a couple months back (at
> PhoenixCon,
> > as
> > > > it
> > > > > happens; they feel the pain as well) about our branch situation.
> I'll
> > > let
> > > > > the others chime in with more details, but the gist as I recall is
> > that
> > > > we
> > > > > should be doing more frequent minor releases with fewer patch
> > releases.
> > > > > This pushes stabilization efforts closer to master and also imposes
> > > more
> > > > > strict stability requirements on big new features before they can
> be
> > > > merged
> > > > > off the feature branch.
> > > > >
> > > > > The discussion also brought up the notion of an LTS release line.
> I'm
> > > not
> > > > > sure how this jives with the more fequent minors, but would require
> > > some
> > > > > branch that's so stable that an RM can effectively spin releases
> > blind.
> > > > >
> > > > > On Tue, Aug 8, 2017 at 12:14 AM 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
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >    - A23, Crosstalk
> >
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

--001a113df2188a0ffd05564186c2--