Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
MapReduce >> mail # dev >> Next releases


Sound goods, just a little impedance between what seem to be 2 conflicting
goals:

* what features we target for each release
* train releases

If we want to do train releases at fixed times, then if a feature is not
ready, it catches the next train, no delays of the train because of a
feature. If a bug is delaying the train and a feature becomes ready in the
mean time and it does not stabilize the release, it can jump on board, if
it breaks something, it goes out of the window until the next train.

Also we have do decide what we do with 2.2.1. I would say start wrapping up
the current 2.2 branch and make it the first train.

thx
On Wed, Nov 13, 2013 at 12:55 PM, Arun C Murthy <[EMAIL PROTECTED]> wrote:

>
> On Nov 13, 2013, at 12:38 PM, Sandy Ryza <[EMAIL PROTECTED]> wrote:
>
> > 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.
>
> To be clear, I still think we should be *very* clear about what features
> we target for each release (2.3, 2.4, etc.).
>
> Except, we don't wait infinitely for any specific feature - if we miss a
> 4-6 week window a feature goes to the next train.
>
> Makes sense?
>
> thanks,
> Arun
>
> >
> > -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

Alejandro
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB