On Wed, Nov 13, 2013 at 10:10 AM, Arun C Murthy <a...@hortonworks.com> wrote: > > On Nov 12, 2013, at 1:54 PM, Todd Lipcon <t...@cloudera.com> wrote: > >> On Mon, Nov 11, 2013 at 2:57 PM, Colin McCabe <cmcc...@alumni.cmu.edu>wrote: >> >>> To be honest, I'm not aware of anything in 2.2.1 that shouldn't be >>> there. However, I have only been following the HDFS and common side >>> of things so I may not have the full picture. Arun, can you give a >>> specific example of something you'd like to "blow away"? > > There are bunch of issues in YARN/MapReduce which clearly aren't *critical*, > similarly in HDFS a cursory glance showed up some > *enhancements*/*improvements* in CHANGES.txt which aren't necessary for a > patch release, plus things like: > > HADOOP-9623 > Update jets3t dependency to 0.9.0
I'm fine with reverting HADOOP-9623 from branch-2.2 and pushing it out to branch-2.3. It does bring in httpcore, a dependency that wasn't there before. Colin > > Here is a straw man proposal: > > ---- > A patch (third version) release should only include *blocker* bugs which are > critical from an operational, security or data-integrity issues. > > This way, we can ensure that a minor series release (2.2.x or 2.3.x or 2.4.x) > is always release-able, and more importantly, deploy-able at any point in > time. > > ---- > > Sandy did bring up a related point about timing of releases and the urge for > everyone to cram features/fixes into a dot release. > > So, we could remedy that situation by doing a release every 4-6 weeks (2.3, > 2.4 etc.) and keep the patch releases limited to blocker bugs. > > Thoughts? > > thanks, > Arun > > > > > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity to > which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You.
