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
