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 discussion. Regards, Sangjin On Mon, Jan 23, 2017 at 8:17 AM, Allen Wittenauer <a...@effectivemachines.com> wrote: > > > On Jan 21, 2017, at 7:08 PM, Karthik Kambatla <ka...@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-unsubscr...@hadoop.apache.org > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > >
