- We need to at the least force a reset of expectations w.r.t how trunk and small / medium / incompatible changes there are treated. We should hold off making a release off trunk before this gets fully discussed in the community and we all reach a consensus.
+1. We should hold off any release work off trunk before we reach a consensus. Or more and more developing work/features could be affected just like Larry mentioned. - Reverts (or revert and move to a feature-branch) shouldn’t have been unequivocally done without dropping a note / informing everyone / building consensus. Agree. To revert commits from other committers, I think we need to: 1) provide technical evidence/reason that is solid as rack, like: break functionality, tests, API compatibility, or significantly offend code convention, etc. 2) Making consensus with related contributors/committers based on these technical reasons/evidences. Unfortunately, I didn't see we ever do either thing in this case. - Freaking out on -1’s and reverts - we as a community need to be less stigmatic about -1s / reverts. +1. As a community, I believe we all prefer to work in a more friendly environment. In many cases, -1 without solid reason will frustrate people who are doing contributions. I think we should restraint our -1 unless it is really necessary. Thanks, Junping ________________________________ From: Vinod Kumar Vavilapalli <vino...@apache.org> Sent: Monday, June 06, 2016 9:36 PM To: Andrew Wang Cc: Junping Du; Aaron T. Myers; common-...@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-...@hadoop.apache.org; yarn-...@hadoop.apache.org Subject: Re: Why there are so many revert operations on trunk? Folks, It is truly disappointing how we are escalating situations that can be resolved through basic communication. Things that shouldn’t have happened - After a few objections were raised, commits should have simply stopped before restarting again but only after consensus - Reverts (or revert and move to a feature-branch) shouldn’t have been unequivocally done without dropping a note / informing everyone / building consensus. And no, not even a release-manager gets this free pass. Not on branch-2, not on trunk, not anywhere. - Freaking out on -1’s and reverts - we as a community need to be less stigmatic about -1s / reverts. Trunk releases: This is the other important bit about huge difference of expectations between the two sides w.r.t trunk and branching. Till now, we’ve never made releases out of trunk. So in-progress features that people deemed to not need a feature branch could go into trunk without much trouble. Given that we are now making releases off trunk, I can see (a) the RM saying "no, don’t put in-progress stuff and (b) the contributors saying “no we don’t want the overhead of a branch”. I’ve raised related topics (but only focusing on incompatible changes) before - http://markmail.org/message/m6x73t6srlchywsn - but we never decided anything. We need to at the least force a reset of expectations w.r.t how trunk and small / medium / incompatible changes there are treated. We should hold off making a release off trunk before this gets fully discussed in the community and we all reach a consensus. * Without a user API, there's no way for people to use it, so not much advantage to having it in a release Since the code is separate and probably won't break any existing code, I won't -1 if you want to include this in a release without a user API, but again, I question the utility of including code that can't be used. Clearly, there are two sides to this argument. One side claims the absence of user-facing public / stable APIs, and that for all purposes this is dead-code for everyone other than the few early adopters who want to experiment with it. The other argument is to not put this code before a user API. Again, I’d discuss with fellow community members before making what the other side perceives as unacceptable moves. >From 2.8.0 perspective, it shouldn’t have landed there in the first place - I >have been pushing for a release for a while with help only from a few members >of the community. But if you say that it has no material impact on the user >story, having a by-default switched-off feature that *doesn’t* destabilize the >core release, I’d be willing to let it pass. +Vinod
