Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of lhofhansl@yahoo.com designates
 98.139.213.138 as permitted sender)
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>
 <CANZa=Gt1ZObikswq1yvbUjH2Ah6QP0suNFd_GqkQZiFS2JtU-A@mail.gmail.com>
 <CA+RK=_BND2AiFF6jqRRinfJJfeXGrUpsh+rW7sTpNLdANO5+Yg@mail.gmail.com>
 <CAOtJ30pewJHobm1xe0wwmvrrgsusADdS3CUgUJtC1bMtKUJvkg@mail.gmail.com>
 <1404403762.54476.YahooMailNeo@web140604.mail.bf1.yahoo.com>
 <CAMUu0w8BBqLko9cYkOXGJHiLMXqdoF4vKuqXTsVckSfBEgqdWQ@mail.gmail.com>
Message-ID: <1404561350.61694.YahooMailNeo@web140606.mail.bf1.yahoo.com>
Date: Sat, 5 Jul 2014 04:55:50 -0700
From: lars hofhansl <larsh@apache.org>
Reply-To: lars hofhansl <larsh@apache.org>
Subject: Re: [NOTICE] Branching for 1.0
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
In-Reply-To: 
 <CAMUu0w8BBqLko9cYkOXGJHiLMXqdoF4vKuqXTsVckSfBEgqdWQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="1905101558-263944392-1404561350=:61694"

--1905101558-263944392-1404561350=:61694
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Either way works. Personally I'd remove the 1.0.0 tag since it adds confusi=
on.=0AI guess if you want to distinguish between 0.99 and 1.0 we'd need it,=
 but when would we want that?=0A(I.e. when do we want a 0.99 release with a=
 known blocker/critical issue in it?)=0A=0A-- Lars=0A=0A=0A=0A_____________=
___________________=0A From: Enis S=F6ztutar <enis@apache.org>=0ATo: "dev@h=
base.apache.org" <dev@hbase.apache.org>; lars hofhansl <larsh@apache.org> =
=0ASent: Friday, July 4, 2014 1:29 AM=0ASubject: Re: [NOTICE] Branching for=
 1.0=0A =0A=0AWe only had 4 issues with fixVersion =3D 1.0.0 and status =3D=
 resolved. I=0Amanually removed the labels from those.=0A=0Ahttps://issues.=
apache.org/jira/browse/HBASE-11449?jql=3DfixVersion%20%3D%201.0.0%20AND%20p=
roject%20%3D%20HBASE%20and%20status%20%3D%20resolved=0A=0AKeeping the versi=
on label helps us tag it as a blocker / critical to the=0A1.0 release, no? =
If it is confusing I can remove it.=0A=0ACommitters, please do not tag reso=
lved issues with fixVersion =3D 1.0.0. The=0Anext release from the branch-1=
 branch is 0.99.0.=0A=0AEnis=0A=0A=0A=0A=0A=0A=0AOn Thu, Jul 3, 2014 at 9:0=
9 AM, lars hofhansl <larsh@apache.org> wrote:=0A=0A> We have to get rid of =
the 0.99 or the 1.0.0 tag since they designate the=0A> same branch.=0A> Sin=
ce we mostly used 0.99, we should move all jiras targeted to 1.0.0 to=0A> 0=
.99 and delete the current 1.0.0 version. 0.99 can later be renamed to=0A> =
1.0.0.=0A> (from painful experience... Don't do that retargeting in bulk, s=
ince jira=0A> will remove all other fix versions)=0A>=0A>=0A> -- Lars=0A>=
=0A>=0A>=0A> ________________________________=0A>=A0 From: Anoop John <anoo=
p.hbase@gmail.com>=0A> To: dev@hbase.apache.org=0A> Sent: Tuesday, July 1, =
2014 5:30 PM=0A> Subject: Re: [NOTICE] Branching for 1.0=0A>=0A>=0A> >Start=
ing today, if a patch goes to 0.98 branch, the Fix Version/s field=0A> shou=
ld include 0.98, 0.99 and 2.0.0, right ?=0A>=0A>=0A> Ted asked this..=0A>=
=0A> Same from me=0A>=0A> Fix version to be 0.99=A0 or 1.0.0?=0A>=0A> -Anoo=
p-=0A>=0A>=0A>=0A>=0A> On Wed, Jul 2, 2014 at 5:31 AM, Andrew Purtell <apur=
tell@apache.org>=0A> wrote:=0A>=0A> > I think as 0.98 RM if the consensus i=
s no it shouldn't go into 1.0 I'd=0A> have=0A> > to cancel the pending 0.98=
 RC and revert the change. If we take too long=0A> to=0A> > reach consensus=
 about 1.0 and the 0.98 RC vote carries, that would force=0A> > inclusion i=
nto 1.0. Interesting possibilities. But we do have two=0A> separate=0A> > b=
ranches and two separate release trains - at least - so we'll have to=0A> >=
 figure it out.=0A> >=0A> >=0A> > On Tue, Jul 1, 2014 at 4:50 PM, Nick Dimi=
duk <ndimiduk@gmail.com> wrote:=0A> >=0A> > > On Tue, Jul 1, 2014 at 4:01 P=
M, Enis S=F6ztutar <enis.soz@gmail.com>=0A> > wrote:=0A> > >=0A> > > > One =
other thing we can do is that we can commit the patch to 0.98 if=0A> > you=
=0A> > > > +1, do the RC, but hold on for committing to 1.0. During the RC =
vote=0A> > > > timeframe, we can then reach a consensus for whether the pat=
ch should=0A> > go=0A> > > > into both branches.=0A> > > >=0A> > >=0A> > > =
It would be a shame to loose track of patches because of this=0A> additiona=
l=0A> > > administrative step happening asynchronously from initial push of=
 the=0A> > > commit.=0A> > >=0A> > > On Tue, Jul 1, 2014 at 3:34 PM, Andrew=
 Purtell <apurtell@apache.org>=0A> > > wrote:=0A> > > >=0A> > > > > I agree=
 just about everything related to HBASE-10856 is something=0A> > that=0A> >=
 > > > merits discussion and consensus.=0A> > > > >=0A> > > > > > My main g=
oal for branch-1 is to limit the exposure for unrelated=0A> > > > changes=
=0A> > > > > in the branch for a more stable release=0A> > > > >=0A> > > > =
> This is a goal shared by 0.98 so that's no issue at all.=0A> > > > >=0A> =
> > > > What we should sort out is coordinating RTC on multiple active=0A> =
> > branches.=0A> > > > > For example, it's not possible for me to commit t=
o rolling a 0.98=0A> RC=0A> > > on a=0A> > > > > particular day if we have =
a blocker that needs to go through 1.0=0A> > first,=0A> > > > > since it is=
 not clear for any given commit when or if it will be=0A> > acked=0A> > > >=
 for=0A> > > > > 1.0.=0A> > > > >=0A> > > > >=0A> > > > > On Tue, Jul 1, 20=
14 at 3:29 PM, Enis S=F6ztutar <enis@apache.org>=0A> > wrote:=0A> > > > >=
=0A> > > > > > Agreed that for every feature including security, we should =
be=0A> > > careful=0A> > > > to=0A> > > > > > not create a gap in terms of =
support (release x supporting,=0A> release=0A> > > x+1=0A> > > > > not=0A> =
> > > > > supporting, release x+2 supporting etc).=0A> > > > > >=0A> > > > =
> > My main goal for branch-1 is to limit the exposure for unrelated=0A> > =
> > changes=0A> > > > > in=0A> > > > > > the branch for a more stable relea=
se. If we think that we need to=0A> > > > > > fix/improve some things for 1=
.0 and 0.98.x, it will be ok to=0A> > commit.=0A> > > > Some=0A> > > > > > =
of the items linked under=0A> > > > > > https://issues.apache.org/jira/brow=
se/HBASE-10856=0A> > > > > > imply big changes, but it would be ok to commi=
t those to have a=0A> > clear=0A> > > > > > story.=0A> > > > > >=0A> > > > =
> > I think we can decide on a per-issue/feature basis.=0A> > > > > > Enis=
=0A> > > > > >=0A> > > > > >=0A> > > > > > On Tue, Jul 1, 2014 at 3:16 PM, =
Andrew Purtell <=0A> > apurtell@apache.org>=0A> > > > > > wrote:=0A> > > > =
> >=0A> > > > > > > Now that I think about it more, actually every commit, =
since I=0A> > > don't=0A> > > > > > think=0A> > > > > > > we want a situati=
on where something goes into master and 0.98,=0A> > but=0A> > > > not=0A> >=
 > > > > 1.0.=0A> > > > > > > We should discuss how to handle this.=0A> > >=
 > > > >=0A> > > > > > >=0A> > > > > > > On Tue, Jul 1, 2014 at 3:10 PM, An=
drew Purtell <=0A> > > apurtell@apache.org>=0A> > > > > > > wrote:=0A> > > =
> > > >=0A> > > > > > > > I'm curious what will be the policy for security =
commits? I=0A> > plan=0A> > > to=0A> > > > > > take=0A> > > > > > > > all s=
ecurity changes into 0.98. If we have commits to master=0A> > and=0A> > > >=
 0.98=0A> > > > > > > that=0A> > > > > > > > will result in a serious featu=
re / functionality=0A> discontinuity.=0A> > > > > > > >=0A> > > > > > > >=
=0A> > > > > > > > On Mon, Jun 30, 2014 at 8:56 PM, Enis S=F6ztutar <=0A> >=
 > enis.soz@gmail.com=0A> > > > >=0A> > > > > > > wrote:=0A> > > > > > > >=
=0A> > > > > > > >> I've pushed the branch, named branch-1:=0A> > > > > > >=
 >>=0A> > > > > > > >>=0A> > > > > > > >>=0A> > > > > > >=0A> > > > > >=0A>=
 > > > >=0A> > > >=0A> > >=0A> >=0A> https://git-wip-us.apache.org/repos/as=
f?p=3Dhbase.git;a=3Dshortlog;h=3Drefs/heads/branch-1=0A> > > > > > > >>=0A>=
 > > > > > > >> Please do not commit new features to branch-1 without=0A> p=
inging=0A> > > the=0A> > > > RM=0A> > > > > > > (for=0A> > > > > > > >> 1.0=
 it is me). Bug fixes, and trivial commits can always go=0A> > in.=0A> > > =
> > > > >>=0A> > > > > > > >> That branch still has 0.99.0-SNAPSHOT as the =
version number,=0A> > > since=0A> > > > > > next=0A> > > > > > > >> expecte=
d release from that is 0.99.0. Jenkins build for this=0A> > > > branch=0A> =
> > > > is=0A> > > > > > > >> setup at https://builds.apache.org/view/All/j=
ob/HBase-1.0/.=0A> > It=0A> > > > > builds=0A> > > > > > > >> with=0A> > > =
> > > > >> latest jdk7. I'll try to stabilize the unit tests for the=0A> > =
first=0A> > > > RC.=0A> > > > > > > >>=0A> > > > > > > >> I've changed the =
master version as well. It now builds with=0A> > > > > > > >> 2.0.0-SNAPSHO=
T.=0A> > > > > > > >> Exciting!=0A> > > > > > > >>=0A> > > > > > > >> Enis=
=0A> > > > > > > >>=0A> > > > > >=0A> > > > >=0A> > > > > --=0A> > > > > Be=
st regards,=0A> > > > >=0A> > > > >=A0 =A0 - Andy=0A> > > > >=0A> > > > > P=
roblems worthy of attack prove their worth by hitting back. - Piet=0A> > > =
Hein=0A> > > > > (via Tom White)=0A> > > > >=0A> > > >=0A> > >=0A> >=0A> >=
=0A> >=0A> > --=0A> > Best regards,=0A> >=0A> >=A0 =A0 - Andy=0A> >=0A> > P=
roblems worthy of attack prove their worth by hitting back. - Piet Hein=0A>=
 > (via Tom White)=0A> >=0A>
--1905101558-263944392-1404561350=:61694--