Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of ndimiduk@gmail.com designates
 209.85.220.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAMUu0w9nrfX24=-DUX6fJjY6Mcr+PrargFo7d9DAqb=Wwn-cvA@mail.gmail.com>
References: 
 <CAMUu0w-Ktc3Maj8wmYQuk_51H5iN_7R77aSsSHt_ORVFVa5Wiw@mail.gmail.com>
 <CAGngS9doC3QCqO072upfMuV9CeGq3mf-_irk-0q-+b-_M0OOcQ@mail.gmail.com>
 <CAMUu0w95u8sCFrk+O9ok00OGSf7EzZ-=u8Ch8p7d8HCtUWJLjQ@mail.gmail.com>
 <CA+RK=_DhPnrwn5gxSUo3_va1Dryp62YW_-c5bRW9ra+qFRJFYA@mail.gmail.com>
 <CA+RK=_BRtXae0h0MbM_nuvWsDvvnkxVXWUGv+S+_QUG55Lx6+g@mail.gmail.com>
 <CAMUu0w8Krg5fc5OVgGh-uWCBChG-9i+WoP3gjKTW8v3jvFD2dA@mail.gmail.com>
 <CA+RK=_CVLd_kkbEu0N4UjSHz4jRUg-YF40UGN5KSLsHdV6vmtQ@mail.gmail.com>
 <CAMUu0w9nrfX24=-DUX6fJjY6Mcr+PrargFo7d9DAqb=Wwn-cvA@mail.gmail.com>
From: Nick Dimiduk <ndimiduk@gmail.com>
Date: Tue, 1 Jul 2014 16:50:02 -0700
Message-ID: 
 <CANZa=Gt1ZObikswq1yvbUjH2Ah6QP0suNFd_GqkQZiFS2JtU-A@mail.gmail.com>
Subject: Re: [NOTICE] Branching for 1.0
To: hbase-dev <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=047d7ba970ca597d1704fd2a70a8

--047d7ba970ca597d1704fd2a70a8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 1, 2014 at 4:01 PM, Enis S=C3=B6ztutar <enis.soz@gmail.com> wro=
te:

> 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=C3=B6ztutar <enis@apache.org> wr=
ote:
> >
> > > Agreed that for every feature including security, we should be carefu=
l
> 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=C3=B6ztutar <enis.soz@gma=
il.com
> >
> > > > wrote:
> > > > >
> > > > >> I've pushed the branch, named branch-1:
> > > > >>
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=3Dhbase.git;a=3Dshortlog;h=3Dre=
fs/heads/branch-1
> > > > >>
> > > > >> Please do not commit new features to branch-1 without pinging th=
e
> 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, sin=
ce
> > > 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 Hei=
n
> > (via Tom White)
> >
>

--047d7ba970ca597d1704fd2a70a8--