hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <la...@apache.org>
Subject Re: [NOTICE] Branching for 1.0
Date Thu, 03 Jul 2014 16:28:13 GMT
In the end it just means the RMs (of all versions) need to agree.

At the same time we need to keep the Apache consensus approach. The RM of version X cannot
force a fix into all versions > X (to avoid discontinuities), at the same time the RM of
version Y cannot indiscriminately block fixes to earlier version just because he/she does
not want those.

-- Lars



________________________________
 From: lars hofhansl <larsh@apache.org>
To: "dev@hbase.apache.org" <dev@hbase.apache.org> 
Sent: Thursday, July 3, 2014 9:21 AM
Subject: Re: [NOTICE] Branching for 1.0
 

I agree completely. Unless a fix is specifically fixes an issue that only occurs in version
X it must be in all versions Y > X.
If we don't do that we *will* lose track in delayed, asynchronous fixes, also we cannot close
the jira, and hence need to create forward port jiras. I'd go as far as saying that every
forward port jira would need to be explained.


IMHO this in independent of any RC considerations. The RC voting is happening on an immutable
tag. The RCs of different versions do not need to be sync'ed (i.e. a fix could be in a later
RC in version Y, that's up to the RM), only branches need to be sync'ed.

As usual.. Just my $0.02.

-- Lars



________________________________



From: Andrew Purtell <apurtell@apache.org>
To: "dev@hbase.apache.org" <dev@hbase.apache.org> 
Sent: Tuesday, July 1, 2014 5:01 PM
Subject: Re: [NOTICE] Branching for 1.0


I think as 0.98 RM if the consensus is no it shouldn't go into 1.0 I'd have
to cancel the pending 0.98 RC and revert the change. If we take too long to
reach consensus about 1.0 and the 0.98 RC vote carries, that would force
inclusion into 1.0. Interesting possibilities. But we do have two separate
branches and two separate release trains - at least - so we'll have to
figure it out.


On Tue, Jul 1, 2014 at 4:50 PM, Nick Dimiduk <ndimiduk@gmail.com> wrote:

> On Tue, Jul 1, 2014 at 4:01 PM, Enis Söztutar <enis.soz@gmail.com> wrote:
>
> > One other thing we can do is that we can commit the patch to 0.98 if you
> > +1, do the RC, but hold on for committing to 1.0. During the RC vote
> > timeframe, we can then reach a consensus for whether the patch should go
> > into both branches.
> >
>
> It would be a shame to loose track of patches because of this additional
> administrative step happening asynchronously from initial push of the
> commit.
>
> On Tue, Jul 1, 2014 at 3:34 PM, Andrew Purtell <apurtell@apache.org>
> wrote:
> >
> > > I agree just about everything related to HBASE-10856 is something that
> > > merits discussion and consensus.
> > >
> > > > My main goal for branch-1 is to limit the exposure for unrelated
> > changes
> > > in the branch for a more stable release
> > >
> > > This is a goal shared by 0.98 so that's no issue at all.
> > >
> > > What we should sort out is coordinating RTC on multiple active
> branches.
> > > For example, it's not possible for me to commit to rolling a 0.98 RC
> on a
> > > particular day if we have a blocker that needs to go through 1.0 first,
> > > since it is not clear for any given commit when or if it will be acked
> > for
> > > 1.0.
> > >
> > >
> > > On Tue, Jul 1, 2014 at 3:29 PM, Enis Söztutar <enis@apache.org> wrote:
> > >
> > > > Agreed that for every feature including security, we should be
> careful
> > to
> > > > not create a gap in terms of support (release x supporting, release
> x+1
> > > not
> > > > supporting, release x+2 supporting etc).
> > > >
> > > > My main goal for branch-1 is to limit the exposure for unrelated
> > changes
> > > in
> > > > the branch for a more stable release. If we think that we need to
> > > > fix/improve some things for 1.0 and 0.98.x, it will be ok to commit.
> > Some
> > > > of the items linked under
> > > > https://issues.apache.org/jira/browse/HBASE-10856
> > > > imply big changes, but it would be ok to commit those to have a clear
> > > > story.
> > > >
> > > > I think we can decide on a per-issue/feature basis.
> > > > Enis
> > > >
> > > >
> > > > On Tue, Jul 1, 2014 at 3:16 PM, Andrew Purtell <apurtell@apache.org>
> > > > wrote:
> > > >
> > > > > Now that I think about it more, actually every commit, since I
> don't
> > > > think
> > > > > we want a situation where something goes into master and 0.98, but
> > not
> > > > 1.0.
> > > > > We should discuss how to handle this.
> > > > >
> > > > >
> > > > > On Tue, Jul 1, 2014 at 3:10 PM, Andrew Purtell <
> apurtell@apache.org>
> > > > > wrote:
> > > > >
> > > > > > I'm curious what will be the policy for security commits? I
plan
> to
> > > > take
> > > > > > all security changes into 0.98. If we have commits to master
and
> > 0.98
> > > > > that
> > > > > > will result in a serious feature / functionality discontinuity.
> > > > > >
> > > > > >
> > > > > > On Mon, Jun 30, 2014 at 8:56 PM, Enis Söztutar <
> enis.soz@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > >> I've pushed the branch, named branch-1:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=shortlog;h=refs/heads/branch-1
> > > > > >>
> > > > > >> Please do not commit new features to branch-1 without pinging
> the
> > RM
> > > > > (for
> > > > > >> 1.0 it is me). Bug fixes, and trivial commits can always
go in.
> > > > > >>
> > > > > >> That branch still has 0.99.0-SNAPSHOT as the version number,
> since
> > > > next
> > > > > >> expected release from that is 0.99.0. Jenkins build for
this
> > branch
> > > is
> > > > > >> setup at https://builds.apache.org/view/All/job/HBase-1.0/.
It
> > > builds
> > > > > >> with
> > > > > >> latest jdk7. I'll try to stabilize the unit tests for the
first
> > RC.
> > > > > >>
> > > > > >> I've changed the master version as well. It now builds with
> > > > > >> 2.0.0-SNAPSHOT.
> > > > > >> Exciting!
> > > > > >>
> > > > > >> Enis
> > > > > >>
> > > >
> > >
> > > --
> > > Best regards,
> > >
> > >    - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)



> > >
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message