Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
References: 
 <CADY20s517dVdK9+mmi8uFx2jksKz1n7W8kD5KgGxUG6oCFk7iA@mail.gmail.com>
Message-ID: <1312927181.75787.YahooMailNeo@web65508.mail.ac4.yahoo.com>
Date: Tue, 9 Aug 2011 14:59:41 -0700 (PDT)
From: Andrew Purtell <apurtell@apache.org>
Reply-To: Andrew Purtell <apurtell@apache.org>
Subject: Re: Two requests from a grumpy old man
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
In-Reply-To: 
 <CADY20s517dVdK9+mmi8uFx2jksKz1n7W8kD5KgGxUG6oCFk7iA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I concur with both points more or less.=0A=0ALet me amend #1 slightly for y=
our consideration:=0A=0A=0A=A0 =A0 1) A followup commit is fine so long as =
it includes in the commit message a=A0description of what differs, eg a com=
mit message format like:=A0"Amend HBASE-nnnn.=A0[...]"=0A=0A=0A=A0 =A0 2) A=
 followup commit may never be done "across versions".=0A=0A=0A=A0 =A0 3) Ba=
ckport commits are of course OK so long as the patch is=A0essentially the s=
ame.=0A=0A=0AThis is what Todd proposed without a time limit for amendments=
 leading up to a release. It still respects release boundaries.=0A=0ARegard=
ing #2, I=A0made a mistake once with that and learned my lesson then. Good =
practice to wait a day.=0A=A0=0ABest regards,=0A=0A=0A=A0 =A0- Andy=0A=0APr=
oblems worthy of attack prove their worth by hitting back. - Piet Hein (via=
 Tom White)=0A=0A=0A----- Original Message -----=0A> From: Todd Lipcon <tod=
d@cloudera.com>=0A> To: dev <dev@hbase.apache.org>=0A> Cc: =0A> Sent: Tuesd=
ay, August 9, 2011 1:52 PM=0A> Subject: Two requests from a grumpy old man=
=0A> =0A> Hey folks. Some time over the last three years working on Hadoop =
and=0A> HBase I've turned from a fun loving youth into a grumpy old man. So=
=0A> here are two grumpy requests I've been thinking about of late, on=0A> =
which I'd like to solicit opinions.=0A> =0A> Grumpy request #1=0A> --------=
----------------------=0A> =0A> I commented the following on HBASE-2077 ear=
lier, but figured it was=0A> worth putting on the mailing list as well.=0A>=
 =0A> "In the future could we open separate JIRAs rather than doing a "part=
=0A> 2" when the commits are more than a day apart? It's very difficult to=
=0A> figure out what went on in the history of this JIRA, since it was=0A> =
committed for 0.20 in Dec '09, briefly amended in Feb '10, amendation=0A> p=
artially reverted the next day, and then another change in Jun '11=0A> for =
0.90.4 to solve an entirely different bug than the description=0A> indicate=
s. This makes it very difficult to support past branches or=0A> maintain di=
stributions, since it appears this was fixed long ago but=0A> in fact 0.90.=
3 lacks a major part of the JIRA."=0A> =0A> This happens fairly frequently =
in HBase (I'm guilty of it as well),=0A> and while I appreciate the value o=
f a lightweight process, it does=0A> make it very difficult to track bug fi=
xes when the multiple commits=0A> can cross different point releases. For e=
xample, we often have=0A> customers who have heard of some JIRA number fixi=
ng a problem, and say=0A> "does 0.90.3 include HBASE-nnnn"? A quick look at=
 the history of=0A> 0.90.3 will tell you "yes", when in fact the real under=
lying issue=0A> isn't fixed until 0.90.4, trunk, etc.=0A> =0A> I'd like to =
propose the following guidelines for "followup commits=0A> under the same J=
IRA":=0A> 1) A followup commit is fine so long as it follows within 1 day o=
f the=0A> original commit.=0A> 1a) The followup commit should include in th=
e commit message a=0A> description of what differs, eg a commit message for=
mat like:=0A> "Amend HBASE-nnnn. Followup to previous commit which forgot t=
o include=0A> Foo.java" would be great. Or if it fixes some small bug in th=
e=0A> previous commit, "Amend HBASE-nnnn. Fix bug JD pointed out in=0A> htt=
p://permalink-to-the-jira-comment".=0A> 2) A followup commit may never be d=
one "across versions" - ie if a=0A> JIRA has already been committed to any =
code base that's been released,=0A> it can't be amended after that, even if=
 the fix is trivial.=0A> 3) Backport commits are of course OK so long as th=
e patch is=0A> essentially the same (eg if something's committed to 0.92.0,=
 it can be=0A> backported to 0.90.n if it's basically the same code)=0A> =
=0A> Does this seem reasonable?=0A> =0A> Grumpy request #2=0A> ------------=
-----------------=0A> Recently we've had a lot of great significant contrib=
utions. A lot of=0A> the time they've been committed very quickly -- ie fro=
m patch to=0A> commit in a few hours. This is great for encouraging contrib=
utors, but=0A> I'm worried we may lose some stability or may introduce feat=
ures that=0A> are questionable. For any patches that are complicated or int=
roduce=0A> new APIs, can we try to leave them open for at least a day or tw=
o=0A> before commit?=0A> =0A> =0A> Thanks=0A> -Todd=0A> -- =0A> Todd Lipcon=
=0A> Software Engineer, Cloudera=0A>