> 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 <[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 > > >
