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
