hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Two requests from a grumpy old man
Date Tue, 09 Aug 2011 21:59:41 GMT
I concur with both points more or less.

Let me amend #1 slightly for your consideration:

    1) A followup commit is fine so long as it includes in the commit message a description
of what differs, eg a commit message format like: "Amend HBASE-nnnn. [...]"

    2) A followup commit may never be done "across versions".

    3) Backport commits are of course OK so long as the patch is essentially the same.

This is what Todd proposed without a time limit for amendments leading up to a release. It
still respects release boundaries.

Regarding #2, I made a mistake once with that and learned my lesson then. Good practice to
wait a day.
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)

----- Original Message -----
> From: Todd Lipcon <todd@cloudera.com>
> To: dev <dev@hbase.apache.org>
> Cc: 
> Sent: Tuesday, August 9, 2011 1:52 PM
> Subject: Two requests from a grumpy old man
> 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
> http://permalink-to-the-jira-comment".
> 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?
> Thanks
> -Todd
> -- 
> Todd Lipcon
> Software Engineer, Cloudera

View raw message