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: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
  b=giiYb1kr365X3Tqpxfb5UxtnQH/OzHP+FSv6I4v7Ok4xJGYzY3b51ILH05IGBsdmEwMV29Ch8DSO0CL+md5RIOlPipPkTN+DiTbxU4AnayVIilJqgzY97wFRXFSsy/It+sLVxwZNQjFUDzfmIG8+mhJKCyUUnXjBkwdoJPiMx0Y=;
References: <089rbhqknjjsoly0263snv3o.1362192404331@email.android.com>
 <CAMUu0w_k9gKTv2z8s3=jazx-J1SxKyMtbX9J2gj24U8ePr8rnA@mail.gmail.com>
 <CAPQV63WT-NLb7kCkMTV1=c+tsQd7b55QrKt_drF+B5wtofXeCA@mail.gmail.com>
Message-ID: <1362194653.99724.YahooMailNeo@web140603.mail.bf1.yahoo.com>
Date: Fri, 1 Mar 2013 19:24:13 -0800 (PST)
From: lars hofhansl <larsh@apache.org>
Reply-To: lars hofhansl <larsh@apache.org>
Subject: Re: [DISCUSS] More new feature backports to 0.94.
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
In-Reply-To: 
 <CAPQV63WT-NLb7kCkMTV1=c+tsQd7b55QrKt_drF+B5wtofXeCA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="-1172831624-102607193-1362194653=:99724"

---1172831624-102607193-1362194653=:99724
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

That is only if we do not backport stabilizing "features". There is an =0A"=
opportunity cost" to be paid if we take a too rigorous approach too.=0A=0AT=
ake=0A for example table-locks (which prompted this discussion). With that =
in =0Aplace we can do safe online schema changes (that won't fail and leave=
 =0Athe table in an undefined state when a concurrent split happens), it =
=0Aalso allows for online merge.=0A=0ANow, is that a destabilizing =0A"feat=
ure", or will it make HBase more stable and hence is an "improvement"? Depe=
nds on viewpoint, doesn't it?=0A-- Lars=0A=0A=0A___________________________=
_____=0A From: Jean-Marc Spaggiari <jean-marc@spaggiari.org>=0ATo: dev@hbas=
e.apache.org =0ASent: Friday, March 1, 2013 7:12 PM=0ASubject: Re: [DISCUSS=
] More new feature backports to 0.94.=0A =0A@Lars: No, not any concern abou=
t anything already backported. Just a=0Apreference to #2 because it seems t=
o make things more stable and=0Aeasier to manage. New feature =3D new relea=
se. Given new sub-releases=0Aare for fixes and improvements, but not new fe=
atures. Also, if we=0Abackport a feature in one or many previous releases, =
we will have to=0Abackport also all the fixes each time there will be an is=
sue. So we=0Awill have more maintenant work on previous releases.=0A=0A2013=
/3/1 Enis S=F6ztutar <enis.soz@gmail.com>:=0A> I think the current way of r=
isk vs rewards analysis is working well. We=0A> will just continue doing th=
at on a case by case basis, discussing the=0A> implications on individual i=
ssues.=0A>=0A>=0A>=0A> On Fri, Mar 1, 2013 at 6:46 PM, Lars Hofhansl <lhofh=
ansl@yahoo.com> wrote:=0A>=0A>> BTW are you concerned about any specific ba=
ck port we did in the past? So=0A>> far we have not seen any destabilizatio=
n in any of the 0.94 releases.=0A>>=0A>> Jean-Marc Spaggiari <jean-marc@spa=
ggiari.org> wrote:=0A>>=0A>> >Hi Lars, #2, does it mean you will stop back-=
porting the new features=0A>> >when it will become a "long-term" release? I=
f so, I'm for option #2...=0A>> >=0A>> >JM=0A>> >=0A>> >In your option=0A>>=
 >2013/3/1 Enis S=F6ztutar <enis.soz@gmail.com>:=0A>> >> Thanks Lars, I thi=
nk it is a good listing of the options we have.=0A>> >>=0A>> >> I'll be +1 =
for #1 and #2, with #1 being a preference.=0A>> >>=0A>> >> Enis=0A>> >>=0A>=
> >>=0A>> >> On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <larsh@apache.or=
g> wrote:=0A>> >>=0A>> >>> So it seems that until we have a stable 0.96 (ma=
ybe 0.96.1 or 0.96.2)=0A>> we=0A>> >>> have three options:=0A>> >>> 1. Back=
port new features to 0.94 as we see fit as long as we do not=0A>> >>> desta=
bilize 0.94.=0A>> >>> 2. Declare a certain point release (0.94.6 looks like=
 a good=0A>> candidate) as=0A>> >>> a "long term", create an 0.94.6 branch =
(in addition to the usual 0.94.6=0A>> >>> tag) and than create 0.94.6.x fix=
 only releases. I would volunteer to=0A>> >>> maintain a 0.94.6 branch in a=
ddition to the 0.94 branch.=0A>> >>> 3. Categorically do not backport new f=
eatures into 0.94 and defer to=0A>> 0.95.=0A>> >>>=0A>> >>> I'd be +1 on op=
tion #1 and #2, and -1 on option #3.=0A>> >>>=0A>> >>> -- Lars=0A>> >>>=0A>=
> >>>=0A>> >>>=0A>> >>> ________________________________=0A>> >>>=A0 From: =
Jonathan Hsieh <jon@cloudera.com>=0A>> >>> To: dev@hbase.apache.org; lars h=
ofhansl <larsh@apache.org>=0A>> >>> Sent: Friday, March 1, 2013 3:11 PM=0A>=
> >>> Subject: Re: [DISCUSS] More new feature backports to 0.94.=0A>> >>>=
=0A>> >>> I think we are basically agreeing -- my primary concern is bringi=
ng new=0A>> >>> features in vital paths introduces more risk, I'd rather no=
t backport=0A>> major=0A>> >>> new features unless we achieve a higher leve=
l of assurance through=0A>> system=0A>> >>> and basic fault injection testi=
ng.=0A>> >>>=0A>> >>> For the three current examples -- snapshots, zk table=
 locks, online=0A>> merge=0A>> >>> -- I actually would prefer not including=
 any in apache 0.94.=A0 Of the=0A>> bunch,=0A>> >>> I feel the table locks =
are the most risky since it affects vital paths=0A>> a=0A>> >>> user must u=
se,=A0 where as snapshots and online merge are features that a=0A>> >>> use=
r could choose to use but does not necessarily have to use.=A0 I'll=0A>> vo=
ice=0A>> >>> my concerns, reason for concerns, and justifications on the in=
dividual=0A>> >>> jiras.=0A>> >>>=0A>> >>> I do feel that new features bein=
g in a dev/preview release like 0.95=0A>> aligns=0A>> >>> well and doesn't =
create situations where different versions have=0A>> different=0A>> >>> fea=
ture sets.=A0 New features should be introduced and hardened in a=0A>> >>> =
dev/preview version, and the turn into the production ready versions=0A>> a=
fter=0A>> >>> they've been proven out a bit.=0A>> >>>=0A>> >>> Jon.=0A>> >>=
>=0A>> >>> On Fri, Mar 1, 2013 at 11:00 AM, lars hofhansl <larsh@apache.org=
>=0A>> wrote:=0A>> >>>=0A>> >>> > This is an open source project, as long a=
s there is a volunteer to=0A>> >>> > backport a patch I see no problem with=
 doing this.=0A>> >>> > The only thing we as the community should ensure is=
 that it must be=0A>> >>> > demonstrated that the patch does not destabiliz=
e the 0.94 code base;=0A>> that=0A>> >>> > has to be done on a case by case=
 basis.=0A>> >>> >=0A>> >>> >=0A>> >>> > Also, there is no stable release o=
f HBase other than 0.94 (0.95 is=0A>> not=0A>> >>> > stable, and we specifi=
cally state that it should not be used in=0A>> >>> production).=0A>> >>> >=
=0A>> >>> > -- Lars=0A>> >>> >=0A>> >>> >=0A>> >>> >=0A>> >>> > ___________=
_____________________=0A>> >>> >=A0 From: Jonathan Hsieh <jon@cloudera.com>=
=0A>> >>> > To: dev@hbase.apache.org=0A>> >>> > Sent: Friday, March 1, 2013=
 8:31 AM=0A>> >>> > Subject: [DISCUSS] More new feature backports to 0.94.=
=0A>> >>> >=0A>> >>> > I was thinking more about HBASE-7360 (backport snaps=
hots to 0.94) and=0A>> >>> also=0A>> >>> > saw HBASE-7965 which suggests po=
rting some major-ish features (table=0A>> >>> locks,=0A>> >>> > online merg=
e) in to the apache 0.94 line.=A0  We should chat about=0A>> what we=0A>> >=
>> > want to do about new features and bringing them into stable versions=
=0A>> >>> (0.94=0A>> >>> > today) and in general criteria we use for future=
 versions.=0A>> >>> >=0A>> >>> > This is similar to the snapshots backport =
discussion and earlier=0A>> backport=0A>> >>> > discussions.=A0 Here's my u=
nderstanding of=A0 high level points we=0A>> basically=0A>> >>> > agree upo=
n.=0A>> >>> > * Backporting new features to the previous major version incu=
rs more=0A>> cost=0A>> >>> > when developing new features,=A0 pushes back e=
fforts on making the=0A>> trunk=0A>> >>> > versions and reduces incentive t=
o move to newer versions.=0A>> >>> > * Backporting new features to earlier =
versions (0.9x.0, 0.9x.1) is=0A>> >>> > reasonable since they are generally=
 less stable.=0A>> >>> > * Backporting new features to later version (0.9x.=
5, 0.9x.6) is less=0A>> >>> > reasonable --=A0 (ex: a 0.94.6, or 0.94.7 sho=
uld only include robust=0A>> >>> > features).=0A>> >>> > * Backporting orth=
ogonal features (snapshots) seems less risky than=0A>> core=0A>> >>> > chan=
ging features=0A>> >>> > * An except: If multiple distributions declare int=
ent to backport, it=0A>> >>> makes=0A>> >>> > sense to backport a feature. =
(snapshots for example).=0A>> >>> >=0A>> >>> > Some new circumstances and d=
iscussion topics:=0A>> >>> > * We now have a dev branch (0.95) with looser =
compat requirements=0A>> that we=0A>> >>> > could more readily release with=
 dev/preview versions.=A0 Shouldn't this=0A>> >>> > reduce the need to back=
port features to the apache stable branches?=0A>> >>> Would=0A>> >>> > rele=
ases of these releases "replace" the 0.x.0 or 0.x.1 releases?=0A>> >>> > * =
For major features in later versions we should raise the bar on the=0A>> >>=
> > amount of testing probably be more explicit about what testing is=0A>> =
done=0A>> >>> > (unit tests not suffcient, system testing stories/resports =
a=0A>> >>> requirement).=0A>> >>> > Any other suggestions?=0A>> >>> >=0A>> =
>>> > Jon.=0A>> >>> >=0A>> >>> > --=0A>> >>> > // Jonathan Hsieh (shay)=0A>=
> >>> > // Software Engineer, Cloudera=0A>> >>> > // jon@cloudera.com=0A>> =
>>> >=0A>> >>>=0A>> >>>=0A>> >>>=0A>> >>> --=0A>> >>> // Jonathan Hsieh (sh=
ay)=0A>> >>> // Software Engineer, Cloudera=0A>> >>> // jon@cloudera.com=0A=
>> >>>=0A>>
---1172831624-102607193-1362194653=:99724--