hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: DISCUSS: How can we have less branches?
Date Tue, 08 Aug 2017 17:40:36 GMT
+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

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