> 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 <[email protected]> > To: [email protected]; Andrew Purtell <[email protected]> > 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 <[email protected]> > 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 <[email protected]> >>> To: [email protected]; Andrew Purtell <[email protected]> >>> 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 > <[email protected]> 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 >
