> 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: mapreduce-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-h...@hadoop.apache.org
