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 <apurt...@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 <t...@cloudera.com> >> To: dev@hbase.apache.org; Andrew Purtell <apurt...@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 <apurt...@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 <t...@cloudera.com> >>>> To: dev@hbase.apache.org; Andrew Purtell <apurt...@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 >> <apurt...@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 >> >
