hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Two requests from a grumpy old man
Date Tue, 09 Aug 2011 20:52:14 GMT
Hey folks. Some time over the last three years working on Hadoop and
HBase I've turned from a fun loving youth into a grumpy old man. So
here are two grumpy requests I've been thinking about of late, on
which I'd like to solicit opinions.

Grumpy request #1

I commented the following on HBASE-2077 earlier, but figured it was
worth putting on the mailing list as well.

"In the future could we open separate JIRAs rather than doing a "part
2" when the commits are more than a day apart? It's very difficult to
figure out what went on in the history of this JIRA, since it was
committed for 0.20 in Dec '09, briefly amended in Feb '10, amendation
partially reverted the next day, and then another change in Jun '11
for 0.90.4 to solve an entirely different bug than the description
indicates. This makes it very difficult to support past branches or
maintain distributions, since it appears this was fixed long ago but
in fact 0.90.3 lacks a major part of the JIRA."

This happens fairly frequently in HBase (I'm guilty of it as well),
and while I appreciate the value of a lightweight process, it does
make it very difficult to track bug fixes when the multiple commits
can cross different point releases. For example, we often have
customers who have heard of some JIRA number fixing a problem, and say
"does 0.90.3 include HBASE-nnnn"? A quick look at the history of
0.90.3 will tell you "yes", when in fact the real underlying issue
isn't fixed until 0.90.4, trunk, etc.

I'd like to propose the following guidelines for "followup commits
under the same JIRA":
1) A followup commit is fine so long as it follows within 1 day of the
original commit.
1a) The followup commit should include in the commit message a
description of what differs, eg a commit message format like:
"Amend HBASE-nnnn. Followup to previous commit which forgot to include
Foo.java" would be great. Or if it fixes some small bug in the
previous commit, "Amend HBASE-nnnn. Fix bug JD pointed out in
2) A followup commit may never be done "across versions" - ie if a
JIRA has already been committed to any code base that's been released,
it can't be amended after that, even if the fix is trivial.
3) Backport commits are of course OK so long as the patch is
essentially the same (eg if something's committed to 0.92.0, it can be
backported to 0.90.n if it's basically the same code)

Does this seem reasonable?

Grumpy request #2
Recently we've had a lot of great significant contributions. A lot of
the time they've been committed very quickly -- ie from patch to
commit in a few hours. This is great for encouraging contributors, but
I'm worried we may lose some stability or may introduce features that
are questionable. For any patches that are complicated or introduce
new APIs, can we try to leave them open for at least a day or two
before commit?

Todd Lipcon
Software Engineer, Cloudera

View raw message