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 lhofhansl@yahoo.com
 designates 72.30.239.201 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>
 <1404404465.86022.YahooMailNeo@web140601.mail.bf1.yahoo.com>
Message-ID: <1404404893.33464.YahooMailNeo@web140602.mail.bf1.yahoo.com>
Date: Thu, 3 Jul 2014 09:28:13 -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>,
  lars hofhansl <larsh@apache.org>
In-Reply-To: <1404404465.86022.YahooMailNeo@web140601.mail.bf1.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="-118416272-1440185264-1404404893=:33464"

---118416272-1440185264-1404404893=:33464
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

In the end it just means the RMs (of all versions) need to agree.=0A=0AAt t=
he same time we need to keep the Apache consensus approach. The RM of versi=
on X cannot force a fix into all versions > X (to avoid discontinuities), a=
t the same time the RM of version Y cannot indiscriminately block fixes to =
earlier version just because he/she does not want those.=0A=0A-- Lars=0A=0A=
=0A=0A________________________________=0A From: lars hofhansl <larsh@apache=
.org>=0ATo: "dev@hbase.apache.org" <dev@hbase.apache.org> =0ASent: Thursday=
, July 3, 2014 9:21 AM=0ASubject: Re: [NOTICE] Branching for 1.0=0A =0A=0AI=
 agree completely. Unless a fix is specifically fixes an issue that only oc=
curs in version X it must be in all versions Y > X.=0AIf we don't do that w=
e *will* lose track in delayed, asynchronous fixes, also we cannot close th=
e jira, and hence need to create forward port jiras. I'd go as far as sayin=
g that every forward port jira would need to be explained.=0A=0A=0AIMHO thi=
s 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 br=
anches need to be sync'ed.=0A=0AAs usual.. Just my $0.02.=0A=0A-- Lars=0A=
=0A=0A=0A________________________________=0A=0A=0A=0AFrom: Andrew Purtell <=
apurtell@apache.org>=0ATo: "dev@hbase.apache.org" <dev@hbase.apache.org> =
=0ASent: Tuesday, July 1, 2014 5:01 PM=0ASubject: Re: [NOTICE] Branching fo=
r 1.0=0A=0A=0AI think as 0.98 RM if the consensus is no it shouldn't go int=
o 1.0 I'd have=0Ato cancel the pending 0.98 RC and revert the change. If we=
 take too long to=0Areach consensus about 1.0 and the 0.98 RC vote carries,=
 that would force=0Ainclusion into 1.0. Interesting possibilities. But we d=
o have two separate=0Abranches and two separate release trains - at least -=
 so we'll have to=0Afigure it out.=0A=0A=0AOn Tue, Jul 1, 2014 at 4:50 PM, =
Nick Dimiduk <ndimiduk@gmail.com> wrote:=0A=0A> On Tue, Jul 1, 2014 at 4:01=
 PM, Enis S=F6ztutar <enis.soz@gmail.com> wrote:=0A>=0A> > One other thing =
we can do is that we can commit the patch to 0.98 if you=0A> > +1, do the R=
C, but hold on for committing to 1.0. During the RC vote=0A> > timeframe, w=
e can then reach a consensus for whether the patch should go=0A> > into bot=
h branches.=0A> >=0A>=0A> It would be a shame to loose track of patches bec=
ause of this additional=0A> administrative step happening asynchronously fr=
om 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 that=0A> > > merits di=
scussion and consensus.=0A> > >=0A> > > > My main goal for branch-1 is to l=
imit the exposure for unrelated=0A> > changes=0A> > > in the branch for a m=
ore 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 RT=
C on multiple active=0A> branches.=0A> > > For example, it's not possible f=
or me to commit to rolling a 0.98 RC=0A> on a=0A> > > particular day if we =
have a blocker that needs to go through 1.0 first,=0A> > > since it is not =
clear for any given commit when or if it will be acked=0A> > for=0A> > > 1.=
0.=0A> > >=0A> > >=0A> > > On Tue, Jul 1, 2014 at 3:29 PM, Enis S=F6ztutar =
<enis@apache.org> wrote:=0A> > >=0A> > > > Agreed that for every feature in=
cluding security, we should be=0A> careful=0A> > to=0A> > > > not create a =
gap in terms of support (release x supporting, 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 release. If we think tha=
t we need to=0A> > > > fix/improve some things for 1.0 and 0.98.x, it will =
be ok to commit.=0A> > Some=0A> > > > of the items linked under=0A> > > > h=
ttps://issues.apache.org/jira/browse/HBASE-10856=0A> > > > imply big change=
s, but it would be ok to commit those to have a 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, Andre=
w Purtell <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 situation where something goes into master =
and 0.98, 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, Andrew Purtell <=0A> apurtell@apache.org>=0A> > > > > wrote:=0A> > >=
 > >=0A> > > > > > I'm curious what will be the policy for security commits=
? I plan=0A> to=0A> > > > take=0A> > > > > > all security changes into 0.98=
. If we have commits to master and=0A> > 0.98=0A> > > > > that=0A> > > > > =
> will result in a serious feature / functionality discontinuity.=0A> > > >=
 > >=0A> > > > > >=0A> > > > > > On Mon, Jun 30, 2014 at 8:56 PM, Enis S=F6=
ztutar <=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> https://git-=
wip-us.apache.org/repos/asf?p=3Dhbase.git;a=3Dshortlog;h=3Drefs/heads/branc=
h-1=0A> > > > > >>=0A> > > > > >> Please do not commit new features to bran=
ch-1 without pinging=0A> the=0A> > RM=0A> > > > > (for=0A> > > > > >> 1.0 i=
t is me). Bug fixes, and trivial commits can always go in.=0A> > > > > >>=
=0A> > > > > >> That branch still has 0.99.0-SNAPSHOT as the version number=
,=0A> since=0A> > > > next=0A> > > > > >> expected release from that is 0.9=
9.0. Jenkins build for this=0A> > branch=0A> > > is=0A> > > > > >> setup at=
 https://builds.apache.org/view/All/job/HBase-1.0/. It=0A> > > builds=0A> >=
 > > > >> with=0A> > > > > >> latest jdk7. I'll try to stabilize the unit t=
ests for the first=0A> > RC.=0A> > > > > >>=0A> > > > > >> I've changed the=
 master version as well. It now builds with=0A> > > > > >> 2.0.0-SNAPSHOT.=
=0A> > > > > >> Exciting!=0A> > > > > >>=0A> > > > > >> Enis=0A> > > > > >>=
=0A> > > >=0A> > >=0A> > > --=0A> > > Best regards,=0A> > >=0A> > >=A0 =A0 =
- Andy=0A> > >=0A> > > Problems worthy of attack prove their worth by hitti=
ng back. - Piet=0A> Hein=0A> > > (via Tom White)=0A=0A=0A=0A> > >=0A> >=0A>=
=0A=0A=0A=0A-- =0ABest regards,=0A=0A=A0=A0 - Andy=0A=0AProblems worthy of =
attack prove their worth by hitting back. - Piet Hein=0A(via Tom White)
---118416272-1440185264-1404404893=:33464--