Here are few patches that I put into 2.2.1 and are minimally invasive, but I don't think are blockers:
YARN-305. Fair scheduler logs too many "Node offered to app" messages. YARN-1335. Move duplicate code from FSSchedulerApp and FiCaSchedulerApp into SchedulerApplication YARN-1333. Support blacklisting in the Fair Scheduler YARN-1109. Demote NodeManager "Sending out status for container" logs to debug (haosdent via Sandy Ryza) YARN-1388. Fair Scheduler page always displays blank fair share +1 to doing releases at some fixed time interval. -Sandy 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 > > > > > > > > > > Having said that, the HDFS devs know their code the best. > > > I agree with Colin. If we've been backporting things into a patch release > > (third version component) which don't belong, we should explicitly call > out > > those patches, so we can learn from our mistakes and have a discussion > > about what belongs. > > Good point. > > 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. >
