hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sangjin Lee <sj...@apache.org>
Subject Re: [VOTE] Release cadence and EOL
Date Mon, 23 Jan 2017 17:49:51 GMT
I'm going to stop the vote and go back to the discussion. It shouldn't be a
big surprise given the reservation we have so far.

I do hope there will be some actionable outcome as a result of that


On Mon, Jan 23, 2017 at 8:17 AM, Allen Wittenauer <aw@effectivemachines.com>

> > On Jan 21, 2017, at 7:08 PM, Karthik Kambatla <kasha@cloudera.com>
> wrote:
> >
> >   3. RM: some method to madness. Junping, for instance, is trying to roll
> >   a release with 2300 patches. It is a huge time investment. (Thanks
> again,
> >   Junping.) Smaller releases are easier to manage. A target release
> cadence,
> >   coupled with a process that encourages volunteering, IMO would lead to
> more
> >   committers doing releases.
>         In the case of 2.8.0, that's on the original RM and "back port
> fever" that inflicts way too many committers.  2.8.0 has been sitting in a
> separate branch for over a year.  Of *course* it is going to be a
> disaster.  If the original RM had said "I don't have time, someone take
> over" after 3 months of it being left idle or another committer feeling as
> though they could take it or not everyone dumping everything they can in
> every release possible, it wouldn't be nearly as bad.
>         Not only do we need to encourage volunteering, but we also need to
> encourage people to relinquish control. If the PMC wants to enact a
> cadence, then they also must be willing to step in when an RM is
> unresponsive and request someone else take over.  A message every three
> months saying "Yes, I'm still working on it." doesn't really help anyone,
> including the RM.
> > To conclude, the biggest value I see is us (the community) agreeing on
> good
> > practices for our releases and work towards that. Writing it down
> somewhere
> > makes it a little more formal like the compatibility stuff, even if it is
> > not enforceable.
>         So it's exactly like the compatibility stuff. ;)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message