hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <enis....@gmail.com>
Subject Re: [NOTICE] Branching for 1.0
Date Tue, 01 Jul 2014 23:01:57 GMT
I think this situation is applicable times when we have more than one
active branches (which is pretty likely always). 0.96 depends on the
patches getting accepted to 0.98+, etc.

I think we can rely on the committers/RMs judgement on whether an issue is
a bug or not and the implications. Unless a release candidate is about to
be cut or something, I think it should be ok for committers to commit bug
fixes to branches w/o an explicit +1 from the RMs. In that case, if a
blocker is found for 0.98 RC, it should be ok to commit that to all active
branches given that it is a bug fix. For improvements / risky patches, we
can wait for the RM.

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.
Enis


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)
>

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