inline....
On Mon, Jun 6, 2016 at 4:36 PM, Vinod Kumar Vavilapalli <vino...@apache.org> wrote: > 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. > > Agreed. > 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 < > 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. > +1 In essence, by moving commits to a feature branch so that we can release from trunk is creating a "trunk-branch". :) > > * 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
