Colin raised the -1 demanding a design document. The document was added the very next day. There were constructive discussions on the design. There was a demand for listenable future or futures with callback, which was accepted to accommodate. Rest of the work having been completed, there was no need to revert. Andrew’s objection was primarily against releasing in 2.8 without the aforementioned change in API, which is reasonable and, IMO, it should be possible to make the above improvement within 2.8 timeline.
On Jun 6, 2016, at 10:13 AM, Chris Douglas <cdoug...@apache.org> wrote: > Reading through HDFS-9924, a request for a design doc- and a -1 on > committing to trunk- was raised in mid-May, but commits to trunk > continued. Why is that? Shouldn't this have paused while the details > were discussed? Branching is neutral to the pace of feature > development, but consensus on the result is required. Working through > possibilities in a branch- or in multiple branches- seems like a > reasonable way to determine which approach has support and code to > back it. > > Reverting code is not "illegal"; the feature will be in/out of any > release by appealing to bylaws. Our rules exist to facilitate > consensus, not declare it a fiat accompli. > > An RM only exists by creating an RC. Someone can declare themselves > Grand Marshall of trunk and stomp around in a fancy hat, but it > doesn't affect anything. -C > > > On Mon, Jun 6, 2016 at 9:36 AM, Junping Du <j...@hortonworks.com> wrote: >> Thanks Aaron for pointing it out. I didn't see any consensus on HDFS-9924 so >> I think we should bring it here with broader audiences for more discussions. >> >> I saw several very bad practices here: >> >> 1. committer (no need to say who) revert all commits from trunk without >> making consensus with all related contributors/committers. >> >> 2. Someone's comments on feature branch are very misleading... If I didn't >> remember wrong, feature development doesn't have to go through feature >> branch which is just an optional process. This creative process of feature >> branch and branch committer - I believe the intention is trying to >> accelerate features development but not to slow them down. >> >> 3. Someone (again, no need to say who) seems to claim himself as RM for >> trunk. I don't think we need any RM for trunk. Even for RM of 3.0.0-alpha, I >> think we need someone else who demonstrates he/she is more responsible, work >> hardly and carefully and open communication with all community. Only through >> this, the success of Hadoop in age of 3.0 are guranteed. >> >> >> Thanks, >> >> >> Junping >> >> >> ________________________________ >> From: Aaron T. Myers <a...@cloudera.com> >> Sent: Monday, June 06, 2016 4:46 PM >> To: Junping Du >> Cc: Andrew Wang; common-...@hadoop.apache.org; hdfs-...@hadoop.apache.org; >> mapreduce-dev@hadoop.apache.org; yarn-...@hadoop.apache.org >> Subject: Re: Why there are so many revert operations on trunk? >> >> Junping, >> >> All of this is being discussed on HDFS-9924. Suggest you follow the >> conversation there. >> >> -- >> Aaron T. Myers >> Software Engineer, Cloudera >> >> On Mon, Jun 6, 2016 at 7:20 AM, Junping Du >> <j...@hortonworks.com<mailto:j...@hortonworks.com>> wrote: >> Hi Andrew, >> >> I just noticed you revert 8 commits on trunk last Friday: >> >> HADOOP-13226 >> >> HDFS-10430 >> >> HDFS-10431 >> >> HDFS-10390 >> >> HADOOP-13168 >> >> HDFS-10390 >> >> HADOOP-13168 >> >> HDFS-10346 >> >> HADOOP-12957 >> >> HDFS-10224 >> >> And I didn't see you have any comments on JIRA or email discussion before >> you did this. I don't think we are legally allowed to do this even as >> committer/PMC member. Can you explain what's your intention to do this? >> >> BTW, thanks Nicolas to revert all these "illegal" revert operations. >> >> >> >> Thanks, >> >> >> Junping >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org > For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: mapreduce-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-dev-h...@hadoop.apache.org
