Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
MapReduce, mail # dev - Next releases


Copy link to this message
-
Re: Next releases
Sandy Ryza 2013-11-13, 18:38
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 <[EMAIL PROTECTED]> wrote:

>
> On Nov 12, 2013, at 1:54 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Nov 11, 2013 at 2:57 PM, Colin McCabe <[EMAIL PROTECTED]
> >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.
>