You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Todd Lipcon <to...@cloudera.com> on 2011/08/09 22:52:14 UTC
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
Re: Two requests from a grumpy old man
Posted by Stack <st...@duboce.net>.
On Tue, Aug 9, 2011 at 1:52 PM, Todd Lipcon <to...@cloudera.com> wrote:
> Grumpy request #1
> ------------------------------
...
> 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?
>
Yes.
> 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?
>
>
No problem.
Lets get the above as the 'grumpy' tenets into our contrib doc on wiki
or here in the book (if others agree):
http://hbase.apache.org/book.html#getting.involved
Good on you Todd.
St.Ack
Re: Two requests from a grumpy old man
Posted by Stack <st...@duboce.net>.
I'm up for taking on a ~24 hour bound on a JIRA amend commit where any
changes to a JIRA outside this time bound would require a new JIRA.
I'd be on for doing just because it makes life easier for the
downstream bundlers even though as Andrew notes, it makes for more
JIRAs (of which we have plenty enough already). I'm probably the
person most responsible for the fuzzy JIRA phenomenon and confess that
its lazyness mostly that has me make the commit on the original JIRA a
month later when if feels like I should be opening a new issue.
Else, we set the limit at a week.
Good stuff,
St.Ack
On Mon, Aug 15, 2011 at 1:03 PM, Andrew Purtell <ap...@apache.org> wrote:
>> As I understand it, we are under a review-then-commit model for
>> anything that's not trivial.
>
>
> Yes, but with one +1.
>
> Give it a few days, others may return their attention to the project and test something, and we discover the JIRA is not finished.
>
>> We can add a new "link" type for JIRA, eg "HBASE-1234 is a regression of HBASE-1000".
>
>
> "Link JIRA" or "amend commit" achieve the same ends, but one proliferates JIRA numbers and the other doesn't.
>
> Best regards,
>
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
>
>
> ----- Original Message -----
>> From: Todd Lipcon <to...@cloudera.com>
>> To: dev@hbase.apache.org; Andrew Purtell <ap...@apache.org>
>> Cc:
>> Sent: Monday, August 15, 2011 12:46 PM
>> Subject: Re: Two requests from a grumpy old man
>>
>> On Mon, Aug 15, 2011 at 12:32 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>>>> A day may be too tight, but maybe we can compromise on a few days, or a
>> week?
>>>
>>>
>>> My concern is about providing the community enough opportunity to test a
>> new change or do CTR. A week is reasonable.
>>
>> As I understand it, we are under a review-then-commit model for
>> anything that's not trivial. If we're regularly committing stuff that
>> we think is trivial, and it turns out to introduce problems, then
>> we're doing a bad job of judging triviality, don't you think?
>>
>> As for testing changes, if we discover that something introduced a
>> regression, I'm in favor of opening a new JIRA if it's been more than
>> a day or two. We can add a new "link" type for JIRA, eg
>> "HBASE-1234 is
>> a regression of HBASE-1000". We already have "is caused by", I
>> think.
>>
>> -Todd
>>
>>>> ________________________________
>>>> From: Todd Lipcon <to...@cloudera.com>
>>>> To: dev@hbase.apache.org; Andrew Purtell <ap...@apache.org>
>>>> Sent: Monday, August 15, 2011 11:36 AM
>>>> Subject: Re: Two requests from a grumpy old man
>>>>
>>>> On Wed, Aug 10, 2011 at 1:40 PM, Andrew Purtell
>> <ap...@apache.org> wrote:
>>>>>> Why remove the day limit Andrew?
>>>>>
>>>>>
>>>>> Both proposals seek middle ground between one JIRA that rolls up
>> all related changes, or a bunch of JIRAs for different aspects of a single
>> commit. I think both extremes are best to be avoided. I think Todd's 24 hour
>> limit is overly and artificially constraining and not that realistic for a newly
>> committed change to be well tested by the community. Bounding changes between
>> releases is definitely good for sanity. So is there some time limit in between
>> that has consensus support then?
>>>>>
>>>>>
>>>>>> My guess is that Todd suggested the> 24 hour bound because
>> it simplifies the archeological dig figuring
>>>>>> what hbase civilization was like back when they released
>> 0.90.x?
>>>>>
>>>>> I don't see this as an issue? People generally know how to use
>> grep, and the proposal includes an agreement to use commit messages of the form
>> "Amend HBASE-XXXX".
>>>>
>>>> The issue is mostly one that we run into as distribution maintainers.
>>>> We often have backported some patches from trunk or a branch that
>>>> haven't been included in a release yet - the latest Cloudera release
>>>> is 0.90.3, but includes a few patches from 0.90.4. Our next release
>>>> will probably be 0.90.4, but will include a couple things backported
>>>> from trunk/92. So, it can be confusing when we say "our release has
>>>> HBASE-nnnn", and then the meaning of HBASE-nnnn changes several
>> weeks
>>>> after it was committed.
>>>>
>>>> I understand that this is something that the community may not care
>>>> about, since it's unique to downstream maintainers of patch series.
>>>> But, I am guessing that other folks that maintain branches slightly
>>>> off trunk (eg Facebook, Trend, etc) may have a similar issue with
>>>> integrating changes into their production branches?
>>>>
>>>> A day may be too tight, but maybe we can compromise on a few days, or a
>> week?
>>>>
>>>> Todd
>>>> --
>>>> Todd Lipcon
>>>> Software Engineer, Cloudera
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Todd Lipcon
>> Software Engineer, Cloudera
>>
>
Re: Two requests from a grumpy old man
Posted by Andrew Purtell <ap...@apache.org>.
> As I understand it, we are under a review-then-commit model for
> anything that's not trivial.
Yes, but with one +1.
Give it a few days, others may return their attention to the project and test something, and we discover the JIRA is not finished.
> We can add a new "link" type for JIRA, eg "HBASE-1234 is a regression of HBASE-1000".
"Link JIRA" or "amend commit" achieve the same ends, but one proliferates JIRA numbers and the other doesn't.
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
----- Original Message -----
> From: Todd Lipcon <to...@cloudera.com>
> To: dev@hbase.apache.org; Andrew Purtell <ap...@apache.org>
> Cc:
> Sent: Monday, August 15, 2011 12:46 PM
> Subject: Re: Two requests from a grumpy old man
>
> On Mon, Aug 15, 2011 at 12:32 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>>> A day may be too tight, but maybe we can compromise on a few days, or a
> week?
>>
>>
>> My concern is about providing the community enough opportunity to test a
> new change or do CTR. A week is reasonable.
>
> As I understand it, we are under a review-then-commit model for
> anything that's not trivial. If we're regularly committing stuff that
> we think is trivial, and it turns out to introduce problems, then
> we're doing a bad job of judging triviality, don't you think?
>
> As for testing changes, if we discover that something introduced a
> regression, I'm in favor of opening a new JIRA if it's been more than
> a day or two. We can add a new "link" type for JIRA, eg
> "HBASE-1234 is
> a regression of HBASE-1000". We already have "is caused by", I
> think.
>
> -Todd
>
>>> ________________________________
>>> From: Todd Lipcon <to...@cloudera.com>
>>> To: dev@hbase.apache.org; Andrew Purtell <ap...@apache.org>
>>> Sent: Monday, August 15, 2011 11:36 AM
>>> Subject: Re: Two requests from a grumpy old man
>>>
>>> On Wed, Aug 10, 2011 at 1:40 PM, Andrew Purtell
> <ap...@apache.org> wrote:
>>>>> Why remove the day limit Andrew?
>>>>
>>>>
>>>> Both proposals seek middle ground between one JIRA that rolls up
> all related changes, or a bunch of JIRAs for different aspects of a single
> commit. I think both extremes are best to be avoided. I think Todd's 24 hour
> limit is overly and artificially constraining and not that realistic for a newly
> committed change to be well tested by the community. Bounding changes between
> releases is definitely good for sanity. So is there some time limit in between
> that has consensus support then?
>>>>
>>>>
>>>>> My guess is that Todd suggested the> 24 hour bound because
> it simplifies the archeological dig figuring
>>>>> what hbase civilization was like back when they released
> 0.90.x?
>>>>
>>>> I don't see this as an issue? People generally know how to use
> grep, and the proposal includes an agreement to use commit messages of the form
> "Amend HBASE-XXXX".
>>>
>>> The issue is mostly one that we run into as distribution maintainers.
>>> We often have backported some patches from trunk or a branch that
>>> haven't been included in a release yet - the latest Cloudera release
>>> is 0.90.3, but includes a few patches from 0.90.4. Our next release
>>> will probably be 0.90.4, but will include a couple things backported
>>> from trunk/92. So, it can be confusing when we say "our release has
>>> HBASE-nnnn", and then the meaning of HBASE-nnnn changes several
> weeks
>>> after it was committed.
>>>
>>> I understand that this is something that the community may not care
>>> about, since it's unique to downstream maintainers of patch series.
>>> But, I am guessing that other folks that maintain branches slightly
>>> off trunk (eg Facebook, Trend, etc) may have a similar issue with
>>> integrating changes into their production branches?
>>>
>>> A day may be too tight, but maybe we can compromise on a few days, or a
> week?
>>>
>>> Todd
>>> --
>>> Todd Lipcon
>>> Software Engineer, Cloudera
>>>
>>>
>>>
>>
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>
Re: Two requests from a grumpy old man
Posted by Todd Lipcon <to...@cloudera.com>.
On Mon, Aug 15, 2011 at 12:32 PM, Andrew Purtell <ap...@apache.org> wrote:
>> A day may be too tight, but maybe we can compromise on a few days, or a week?
>
>
> My concern is about providing the community enough opportunity to test a new change or do CTR. A week is reasonable.
As I understand it, we are under a review-then-commit model for
anything that's not trivial. If we're regularly committing stuff that
we think is trivial, and it turns out to introduce problems, then
we're doing a bad job of judging triviality, don't you think?
As for testing changes, if we discover that something introduced a
regression, I'm in favor of opening a new JIRA if it's been more than
a day or two. We can add a new "link" type for JIRA, eg "HBASE-1234 is
a regression of HBASE-1000". We already have "is caused by", I think.
-Todd
>>________________________________
>>From: Todd Lipcon <to...@cloudera.com>
>>To: dev@hbase.apache.org; Andrew Purtell <ap...@apache.org>
>>Sent: Monday, August 15, 2011 11:36 AM
>>Subject: Re: Two requests from a grumpy old man
>>
>>On Wed, Aug 10, 2011 at 1:40 PM, Andrew Purtell <ap...@apache.org> wrote:
>>>> Why remove the day limit Andrew?
>>>
>>>
>>> Both proposals seek middle ground between one JIRA that rolls up all related changes, or a bunch of JIRAs for different aspects of a single commit. I think both extremes are best to be avoided. I think Todd's 24 hour limit is overly and artificially constraining and not that realistic for a newly committed change to be well tested by the community. Bounding changes between releases is definitely good for sanity. So is there some time limit in between that has consensus support then?
>>>
>>>
>>>> My guess is that Todd suggested the> 24 hour bound because it simplifies the archeological dig figuring
>>>> what hbase civilization was like back when they released 0.90.x?
>>>
>>> I don't see this as an issue? People generally know how to use grep, and the proposal includes an agreement to use commit messages of the form "Amend HBASE-XXXX".
>>
>>The issue is mostly one that we run into as distribution maintainers.
>>We often have backported some patches from trunk or a branch that
>>haven't been included in a release yet - the latest Cloudera release
>>is 0.90.3, but includes a few patches from 0.90.4. Our next release
>>will probably be 0.90.4, but will include a couple things backported
>>from trunk/92. So, it can be confusing when we say "our release has
>>HBASE-nnnn", and then the meaning of HBASE-nnnn changes several weeks
>>after it was committed.
>>
>>I understand that this is something that the community may not care
>>about, since it's unique to downstream maintainers of patch series.
>>But, I am guessing that other folks that maintain branches slightly
>>off trunk (eg Facebook, Trend, etc) may have a similar issue with
>>integrating changes into their production branches?
>>
>>A day may be too tight, but maybe we can compromise on a few days, or a week?
>>
>>Todd
>>--
>>Todd Lipcon
>>Software Engineer, Cloudera
>>
>>
>>
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: Two requests from a grumpy old man
Posted by Andrew Purtell <ap...@apache.org>.
> A day may be too tight, but maybe we can compromise on a few days, or a week?
My concern is about providing the community enough opportunity to test a new change or do CTR. A week is reasonable.
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
>________________________________
>From: Todd Lipcon <to...@cloudera.com>
>To: dev@hbase.apache.org; Andrew Purtell <ap...@apache.org>
>Sent: Monday, August 15, 2011 11:36 AM
>Subject: Re: Two requests from a grumpy old man
>
>On Wed, Aug 10, 2011 at 1:40 PM, Andrew Purtell <ap...@apache.org> wrote:
>>> Why remove the day limit Andrew?
>>
>>
>> Both proposals seek middle ground between one JIRA that rolls up all related changes, or a bunch of JIRAs for different aspects of a single commit. I think both extremes are best to be avoided. I think Todd's 24 hour limit is overly and artificially constraining and not that realistic for a newly committed change to be well tested by the community. Bounding changes between releases is definitely good for sanity. So is there some time limit in between that has consensus support then?
>>
>>
>>> My guess is that Todd suggested the> 24 hour bound because it simplifies the archeological dig figuring
>>> what hbase civilization was like back when they released 0.90.x?
>>
>> I don't see this as an issue? People generally know how to use grep, and the proposal includes an agreement to use commit messages of the form "Amend HBASE-XXXX".
>
>The issue is mostly one that we run into as distribution maintainers.
>We often have backported some patches from trunk or a branch that
>haven't been included in a release yet - the latest Cloudera release
>is 0.90.3, but includes a few patches from 0.90.4. Our next release
>will probably be 0.90.4, but will include a couple things backported
>from trunk/92. So, it can be confusing when we say "our release has
>HBASE-nnnn", and then the meaning of HBASE-nnnn changes several weeks
>after it was committed.
>
>I understand that this is something that the community may not care
>about, since it's unique to downstream maintainers of patch series.
>But, I am guessing that other folks that maintain branches slightly
>off trunk (eg Facebook, Trend, etc) may have a similar issue with
>integrating changes into their production branches?
>
>A day may be too tight, but maybe we can compromise on a few days, or a week?
>
>Todd
>--
>Todd Lipcon
>Software Engineer, Cloudera
>
>
>
Re: Two requests from a grumpy old man
Posted by Andrew Purtell <ap...@apache.org>.
> Actually, I think that anybody who maintains any kind of reference to a JIRA
> whether in a distribution or in their own head would like the meaning of a
> JIRA to be relatively static.
I don't remember proposing to change the meaning of a JIRA with amendments. This is a separate conversation.
I suppose in theory if we leave open the possibility for committers to amend a commit for a week they can do anything, but what I see with HBase anyway is amendments fix problems introduced by the change, or add missing files to fix the build.
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
----- Original Message -----
> From: Ted Dunning <td...@maprtech.com>
> To: dev@hbase.apache.org
> Cc: Andrew Purtell <ap...@apache.org>
> Sent: Monday, August 15, 2011 11:45 AM
> Subject: Re: Two requests from a grumpy old man
>
> Actually, I think that anybody who maintains any kind of reference to a JIRA
> whether in a distribution or in their own head would like the meaning of a
> JIRA to be relatively static.
>
> So even if the community doesn't explicitly know that they care about this,
> I bet they care about the consequences.
>
> On Mon, Aug 15, 2011 at 11:36 AM, Todd Lipcon <to...@cloudera.com> wrote:
>
>> I understand that this is something that the community may not care
>> about, since it's unique to downstream maintainers of patch series.
>> But, I am guessing that other folks that maintain branches slightly
>> off trunk (eg Facebook, Trend, etc) may have a similar issue with
>> integrating changes into their production branches?
>>
>> A day may be too tight, but maybe we can compromise on a few days, or a
>> week?
>>
>
Re: Two requests from a grumpy old man
Posted by Ted Dunning <td...@maprtech.com>.
Actually, I think that anybody who maintains any kind of reference to a JIRA
whether in a distribution or in their own head would like the meaning of a
JIRA to be relatively static.
So even if the community doesn't explicitly know that they care about this,
I bet they care about the consequences.
On Mon, Aug 15, 2011 at 11:36 AM, Todd Lipcon <to...@cloudera.com> wrote:
> I understand that this is something that the community may not care
> about, since it's unique to downstream maintainers of patch series.
> But, I am guessing that other folks that maintain branches slightly
> off trunk (eg Facebook, Trend, etc) may have a similar issue with
> integrating changes into their production branches?
>
> A day may be too tight, but maybe we can compromise on a few days, or a
> week?
>
Re: Two requests from a grumpy old man
Posted by Todd Lipcon <to...@cloudera.com>.
On Wed, Aug 10, 2011 at 1:40 PM, Andrew Purtell <ap...@apache.org> wrote:
>> Why remove the day limit Andrew?
>
>
> Both proposals seek middle ground between one JIRA that rolls up all related changes, or a bunch of JIRAs for different aspects of a single commit. I think both extremes are best to be avoided. I think Todd's 24 hour limit is overly and artificially constraining and not that realistic for a newly committed change to be well tested by the community. Bounding changes between releases is definitely good for sanity. So is there some time limit in between that has consensus support then?
>
>
>> My guess is that Todd suggested the> 24 hour bound because it simplifies the archeological dig figuring
>> what hbase civilization was like back when they released 0.90.x?
>
> I don't see this as an issue? People generally know how to use grep, and the proposal includes an agreement to use commit messages of the form "Amend HBASE-XXXX".
The issue is mostly one that we run into as distribution maintainers.
We often have backported some patches from trunk or a branch that
haven't been included in a release yet - the latest Cloudera release
is 0.90.3, but includes a few patches from 0.90.4. Our next release
will probably be 0.90.4, but will include a couple things backported
from trunk/92. So, it can be confusing when we say "our release has
HBASE-nnnn", and then the meaning of HBASE-nnnn changes several weeks
after it was committed.
I understand that this is something that the community may not care
about, since it's unique to downstream maintainers of patch series.
But, I am guessing that other folks that maintain branches slightly
off trunk (eg Facebook, Trend, etc) may have a similar issue with
integrating changes into their production branches?
A day may be too tight, but maybe we can compromise on a few days, or a week?
Todd
--
Todd Lipcon
Software Engineer, Cloudera
Re: Two requests from a grumpy old man
Posted by Ted Yu <yu...@gmail.com>.
For proposal #2, is weekend included or excluded ?
I personally have more time working on HBase during weekend.
Cheers
On Wed, Aug 10, 2011 at 1:40 PM, Andrew Purtell <ap...@apache.org> wrote:
> > Why remove the day limit Andrew?
>
>
> Both proposals seek middle ground between one JIRA that rolls up all
> related changes, or a bunch of JIRAs for different aspects of a single
> commit. I think both extremes are best to be avoided. I think Todd's 24 hour
> limit is overly and artificially constraining and not that realistic for a
> newly committed change to be well tested by the community. Bounding changes
> between releases is definitely good for sanity. So is there some time limit
> in between that has consensus support then?
>
>
> > My guess is that Todd suggested the> 24 hour bound because it simplifies
> the archeological dig figuring
> > what hbase civilization was like back when they released 0.90.x?
>
> I don't see this as an issue? People generally know how to use grep, and
> the proposal includes an agreement to use commit messages of the form "Amend
> HBASE-XXXX".
>
> Best regards,
>
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
>
> ----- Original Message -----
> > From: Stack <st...@duboce.net>
> > To: dev@hbase.apache.org; Andrew Purtell <ap...@apache.org>
> > Cc:
> > Sent: Wednesday, August 10, 2011 1:21 PM
> > Subject: Re: Two requests from a grumpy old man
> >
> > On Tue, Aug 9, 2011 at 2:59 PM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >> This is what Todd proposed without a time limit for amendments leading
> up
> > to a release. It still respects release boundaries.
> >>
> >
> > Why remove the day limit Andrew? My guess is that Todd suggested the
> > 24 hour bound because it simplifies the archeological dig figuring
> > what hbase civilization was like back when they released 0.90.x?
> >
> > St.Ack
> >
>
Re: Two requests from a grumpy old man
Posted by Andrew Purtell <ap...@apache.org>.
> Why remove the day limit Andrew?
Both proposals seek middle ground between one JIRA that rolls up all related changes, or a bunch of JIRAs for different aspects of a single commit. I think both extremes are best to be avoided. I think Todd's 24 hour limit is overly and artificially constraining and not that realistic for a newly committed change to be well tested by the community. Bounding changes between releases is definitely good for sanity. So is there some time limit in between that has consensus support then?
> My guess is that Todd suggested the> 24 hour bound because it simplifies the archeological dig figuring
> what hbase civilization was like back when they released 0.90.x?
I don't see this as an issue? People generally know how to use grep, and the proposal includes an agreement to use commit messages of the form "Amend HBASE-XXXX".
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
----- Original Message -----
> From: Stack <st...@duboce.net>
> To: dev@hbase.apache.org; Andrew Purtell <ap...@apache.org>
> Cc:
> Sent: Wednesday, August 10, 2011 1:21 PM
> Subject: Re: Two requests from a grumpy old man
>
> On Tue, Aug 9, 2011 at 2:59 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>> This is what Todd proposed without a time limit for amendments leading up
> to a release. It still respects release boundaries.
>>
>
> Why remove the day limit Andrew? My guess is that Todd suggested the
> 24 hour bound because it simplifies the archeological dig figuring
> what hbase civilization was like back when they released 0.90.x?
>
> St.Ack
>
Re: Two requests from a grumpy old man
Posted by Stack <st...@duboce.net>.
On Tue, Aug 9, 2011 at 2:59 PM, Andrew Purtell <ap...@apache.org> wrote:
> This is what Todd proposed without a time limit for amendments leading up to a release. It still respects release boundaries.
>
Why remove the day limit Andrew? My guess is that Todd suggested the
24 hour bound because it simplifies the archeological dig figuring
what hbase civilization was like back when they released 0.90.x?
St.Ack
Re: Two requests from a grumpy old man
Posted by Andrew Purtell <ap...@apache.org>.
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 <to...@cloudera.com>
> To: dev <de...@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
>