Why there are so many revert operations on trunk?

[Junping Du <jd...@hortonworks.com>]

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

Re: Why there are so many revert operations on trunk?

[larry mccay <lm...@apache.org>]

This seems like something that is going to probably happen again if we
continue to cut releases from trunk.
I know that this has been discussed at length in a separate thread but I
think it would be good to recognize that it is the core of the issue here.

Either we:

* need to define what will happen on trunk in such circumstances and
clearly communicate an action before taking it on the dev@ list or
* we need to not introduce this sort of thrashing on trunk by releasing
from it directly

My humble 2 cents...

--larry


On Mon, Jun 6, 2016 at 1:56 PM, Andrew Wang <an...@cloudera.com>
wrote:

> To clarify what happened here, I moved the commits to a feature branch, not
> just reverting the commits. The intent was to make it easy to merge back in
> later, and also to unblock the 2.8 and 3.0 releases we've been trying very
> hard to wrap up for weeks. This doesn't slow down development since you can
> keep committing to a branch, and I did the git work to make it easy to
> merge back in alter. I'm also happy to review the merge if the concern is
> getting three +1s.
>
> In the comments on HDFS-9924, you can see comments from a month ago raising
> concerns about the API and also that this significant expansion of the HDFS
> API is being done on release branches. There is an explicit -1 on continued
> commits to trunk, and a request to move the commits to a feature branch.
> Similar concerns have been raised by multiple contributors on that JIRA.
> Yet, the commits remained in release branches, and new patches continued to
> be committed to release branches.
>
> There's no need to attribute malicious intent to slow down feature
> development; for some reason I keep seeing this accusation thrown around
> when there are many people chiming in on HDFS-9924 with concerns about the
> feature. Considering how it's expanding the HDFS API, this is also the kind
> of work that should go through a merge vote anyway to get more eyes on it.
>
> We've been converging on the API requirements, but until the user-facing
> API is ready, I don't see the advantage of having this code in a release
> branch. As noted by the contributors on this JIRA, it's new separate code,
> so there's little to no overhead to keeping a feature branch in sync.
>
> So, to sum it up, I moved these commits to a branch because:
>
> * The discussion about the user API is still ongoing, and there is
> currently no user-facing API
> * We are very late in the 2.8 and 3.0 release cycles, trying to do blocker
> burndown
> * This code is separate and thus easy to keep in sync on a branch and merge
> in later
> * 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.
>
> Thanks,
> Andrew
>

Re: Why there are so many revert operations on trunk?

[larry mccay <lm...@apache.org>]

This seems like something that is going to probably happen again if we
continue to cut releases from trunk.
I know that this has been discussed at length in a separate thread but I
think it would be good to recognize that it is the core of the issue here.

Either we:

* need to define what will happen on trunk in such circumstances and
clearly communicate an action before taking it on the dev@ list or
* we need to not introduce this sort of thrashing on trunk by releasing
from it directly

My humble 2 cents...

--larry


On Mon, Jun 6, 2016 at 1:56 PM, Andrew Wang <an...@cloudera.com>
wrote:

> To clarify what happened here, I moved the commits to a feature branch, not
> just reverting the commits. The intent was to make it easy to merge back in
> later, and also to unblock the 2.8 and 3.0 releases we've been trying very
> hard to wrap up for weeks. This doesn't slow down development since you can
> keep committing to a branch, and I did the git work to make it easy to
> merge back in alter. I'm also happy to review the merge if the concern is
> getting three +1s.
>
> In the comments on HDFS-9924, you can see comments from a month ago raising
> concerns about the API and also that this significant expansion of the HDFS
> API is being done on release branches. There is an explicit -1 on continued
> commits to trunk, and a request to move the commits to a feature branch.
> Similar concerns have been raised by multiple contributors on that JIRA.
> Yet, the commits remained in release branches, and new patches continued to
> be committed to release branches.
>
> There's no need to attribute malicious intent to slow down feature
> development; for some reason I keep seeing this accusation thrown around
> when there are many people chiming in on HDFS-9924 with concerns about the
> feature. Considering how it's expanding the HDFS API, this is also the kind
> of work that should go through a merge vote anyway to get more eyes on it.
>
> We've been converging on the API requirements, but until the user-facing
> API is ready, I don't see the advantage of having this code in a release
> branch. As noted by the contributors on this JIRA, it's new separate code,
> so there's little to no overhead to keeping a feature branch in sync.
>
> So, to sum it up, I moved these commits to a branch because:
>
> * The discussion about the user API is still ongoing, and there is
> currently no user-facing API
> * We are very late in the 2.8 and 3.0 release cycles, trying to do blocker
> burndown
> * This code is separate and thus easy to keep in sync on a branch and merge
> in later
> * 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.
>
> Thanks,
> Andrew
>

Re: Why there are so many revert operations on trunk?

[larry mccay <lm...@apache.org>]

inline....


On Mon, Jun 6, 2016 at 4:36 PM, Vinod Kumar Vavilapalli <vi...@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

Re: Why there are so many revert operations on trunk?

[Ravi Prakash <ra...@gmail.com>]

Lolz!

Thanks for your opinion Larry. I have often seen "-1 until this is done
according to my way rather than your way" (obviously not in those words),
even when both ways are perfectly reasonable. Anyway, I didn't expect the
voting rules to change. :-)

Cheers
Ravi

On Tue, Jun 7, 2016 at 11:02 AM, larry mccay <la...@gmail.com> wrote:

> -1 needs not be a taken as a derogatory statement being a number should
> actually make it less emotional.
> It is dangerous to a community to become oversensitive to it.
>
> I generally see language such as "I am -1 on this until this particular
> thing is fixed" or that it violates some common pattern or precedence set
> in the project. This is perfectly reasonable language and there is no
> reason to make the reviewer provide an alternative.
>
> So, I am giving my -1 to any proposal for rule changes on -1 votes. :)
>
>
> On Tue, Jun 7, 2016 at 1:15 PM, Ravi Prakash <ra...@gmail.com> wrote:
>
>> +1 on being more respectful. We seem to be having a lot of distasteful
>> discussions recently. If we fight each other, we are only helping our
>> competitors win (and trust me, its out there).
>>
>> I would also respectfully request people not to throw -1s around. I have
>> faced this a few times and its really frustrating. Every one has opinions
>> and some times different people can't fathom why someone else thinks the
>> way they do. I am pretty sure none of us is acting with malicious intent,
>> so perhaps a little more tolerance, faith and trust will help all of us
>> improve Hadoop and the ecosystem much faster. That's not to say that
>> sometimes -1s are not warranted, but we should look to it as an extreme
>> measure. Unfortunately there is very little disincentive right now to vote
>> -1 . Maybe we should modify the rules..... if you vote -1 , you have to
>> come up with an alternative implementation? (perhaps limit the amount of
>> time you have to the amount already spent in producing the patch that you
>> are against)?
>>
>> Just my 2 cents
>> Ravi
>>
>>
>> On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <jd...@hortonworks.com> wrote:
>>
>> > - 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 <vi...@apache.org>
>> > Sent: Monday, June 06, 2016 9:36 PM
>> > To: Andrew Wang
>> > Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org;
>> > hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
>> > yarn-dev@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
>> >
>>
>
>

Re: Why there are so many revert operations on trunk?

[Ravi Prakash <ra...@gmail.com>]

Lolz!

Thanks for your opinion Larry. I have often seen "-1 until this is done
according to my way rather than your way" (obviously not in those words),
even when both ways are perfectly reasonable. Anyway, I didn't expect the
voting rules to change. :-)

Cheers
Ravi

On Tue, Jun 7, 2016 at 11:02 AM, larry mccay <la...@gmail.com> wrote:

> -1 needs not be a taken as a derogatory statement being a number should
> actually make it less emotional.
> It is dangerous to a community to become oversensitive to it.
>
> I generally see language such as "I am -1 on this until this particular
> thing is fixed" or that it violates some common pattern or precedence set
> in the project. This is perfectly reasonable language and there is no
> reason to make the reviewer provide an alternative.
>
> So, I am giving my -1 to any proposal for rule changes on -1 votes. :)
>
>
> On Tue, Jun 7, 2016 at 1:15 PM, Ravi Prakash <ra...@gmail.com> wrote:
>
>> +1 on being more respectful. We seem to be having a lot of distasteful
>> discussions recently. If we fight each other, we are only helping our
>> competitors win (and trust me, its out there).
>>
>> I would also respectfully request people not to throw -1s around. I have
>> faced this a few times and its really frustrating. Every one has opinions
>> and some times different people can't fathom why someone else thinks the
>> way they do. I am pretty sure none of us is acting with malicious intent,
>> so perhaps a little more tolerance, faith and trust will help all of us
>> improve Hadoop and the ecosystem much faster. That's not to say that
>> sometimes -1s are not warranted, but we should look to it as an extreme
>> measure. Unfortunately there is very little disincentive right now to vote
>> -1 . Maybe we should modify the rules..... if you vote -1 , you have to
>> come up with an alternative implementation? (perhaps limit the amount of
>> time you have to the amount already spent in producing the patch that you
>> are against)?
>>
>> Just my 2 cents
>> Ravi
>>
>>
>> On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <jd...@hortonworks.com> wrote:
>>
>> > - 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 <vi...@apache.org>
>> > Sent: Monday, June 06, 2016 9:36 PM
>> > To: Andrew Wang
>> > Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org;
>> > hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
>> > yarn-dev@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
>> >
>>
>
>

RE: Why there are so many revert operations on trunk?

["Zheng, Kai" <ka...@intel.com>]

+1 on we would prefer more to using feature branches on big efforts. Thanks Colin for the insights and details.
For better effect and to make feature branch more attractive, we might also consider to give more love to such feature branches, maybe not so much as we do to trunk. In this thinking, the creation of a feature branch would be notified in the mailing list documenting the proposed change, impact, timeline schedule and etc. for broad attentions. Potential reviewers are encouraged to participate in the development discussions from beginning or earlier to make later merge vote easier to pass. 

+1 on we should be more respectful. Contributing is already hard enough. Working on Hadoop should be more fun. Is contribution to Hadoop still a very cool thing as it was some time before say 5 years ago? The community should be more united and work together more efficiently on the major things, for example Hadoop 3.0 release, EC, Ozone and this HDFS async support, to make these wonderful features  be available to users as earlier as possible. It's fast evolving, users can't wait too long. 

+1 on we should avoid reverting back and forth. It looks rather messy. I think this was just a special case.

Since it was mentioned, regarding Hadoop 3.0 alpha/beta releases on trunk, the process was discussed before, the progress looks fine and the first release cut is promising, thanks to Andrew and many other guys working on that. If we do big changes on feature branch and merge back to trunk with maturity, this approach should work great to simplify the release things. Could we resolve this soon, proceed and speed up with the 3.0 release? Thanks all.

Regards,
Kai

-----Original Message-----
From: Colin McCabe [mailto:cmccabe@apache.org] 
Sent: Wednesday, June 08, 2016 3:33 AM
To: common-dev@hadoop.apache.org
Subject: Re: Why there are so many revert operations on trunk?

One anti-pattern that keeps coming up over and over again is people trying to do big and complex features without feature branches.  This happened with HDFS truncate as well.  This inevitably leads to controversy because people see very big and invasive patches zooming past and get alarmed.  Devops people see complicated new code going directly into production branches and freak out.  Developers see new APIs getting added without much discussion and start pushing back.

This all gets worse when it's combined with the lack of an up-to-date design doc.  This leads to people asking the same questions over and over, since there's no central place they can go to do background reading about the new feature.  It also tends to lead to arguments, since the design decisions that were made seem to come out of nowhere, rather than being justified by careful consideration of alternatives.

When patches get committed directly to production branches, the discussion also gets mixed up with release management discussions, which are often contentious as well.  Release management discussions can go on for a while at the best of times-- when you combine this with all the above, it just becomes really messy.

My advice is, if 3 or more people ask you for a feature branch, just create a feature branch already!  It makes things a lot simpler and less controversial.  It decouples the feature development discussion from the release management discussion.  It gives developers the ability to look at the feature as a whole, rather than feeling like they have to understand each commit in isolation.  Devops people feel like they can relax because the decision about what stable branches to backport to will be made after they have a chance to clearly understand the new feature, rather than before.  The branch merge email functions as a kind of overview of the feature which makes people more comfortable with it.

Feature branches actually speed up development for medium or large-sized features.  You can have branch committers who are not full committers, but can commit to the branch.  You can rewrite your API at any time without worrying about compatibility.  You can rewrite the history of the branch however you like to explore new approaches.  You don't need to backport each of your patches to N stable branches.

Some people seem scared by the need for a merge vote to merge a feature branch.  But if your feature is big, you are going to get scrutiny anyway.  Committing stuff directly to trunk or branch-2 is a not a "get out of jail free" card that bypasses community review.  If anything, community review will probably be longer and more contentious because of the reasons above.  People get frustrated when commits to production branches continue even while big questions about the feature still remain unanswered.

We already have rules constraining the use of the -1 vote.  Like any other discussion, -1 votes need to be "constructive"-- that is, they need to clearly spell out the way forward, rather than just saying no. 
In this particular case, the concerns we had were about the way the feature was being developed, and the API.

I think that the discussion that is going on for HDFS async right now is healthy, and will lead to a better feature.  We have people from downstream projects such as HBase commenting on the kind of APIs they would find useful.  We have discussions about the impact on the RPC system, and the branches that it makes sense to target.  And now that we have a feature branch, we have a lot more freedom to experiment.

best,
Colin


On Tue, Jun 7, 2016, at 11:02, larry mccay wrote:
> -1 needs not be a taken as a derogatory statement being a number 
> should actually make it less emotional.
> It is dangerous to a community to become oversensitive to it.
> 
> I generally see language such as "I am -1 on this until this 
> particular thing is fixed" or that it violates some common pattern or 
> precedence set in the project. This is perfectly reasonable language 
> and there is no reason to make the reviewer provide an alternative.
> 
> So, I am giving my -1 to any proposal for rule changes on -1 votes. :)
> 
> 
> On Tue, Jun 7, 2016 at 1:15 PM, Ravi Prakash <ra...@gmail.com>
> wrote:
> 
> > +1 on being more respectful. We seem to be having a lot of 
> > +distasteful
> > discussions recently. If we fight each other, we are only helping 
> > our competitors win (and trust me, its out there).
> >
> > I would also respectfully request people not to throw -1s around. I 
> > have faced this a few times and its really frustrating. Every one 
> > has opinions and some times different people can't fathom why 
> > someone else thinks the way they do. I am pretty sure none of us is 
> > acting with malicious intent, so perhaps a little more tolerance, 
> > faith and trust will help all of us improve Hadoop and the ecosystem 
> > much faster. That's not to say that sometimes -1s are not warranted, 
> > but we should look to it as an extreme measure. Unfortunately there 
> > is very little disincentive right now to vote
> > -1 . Maybe we should modify the rules..... if you vote -1 , you have 
> > to come up with an alternative implementation? (perhaps limit the 
> > amount of time you have to the amount already spent in producing the 
> > patch that you are against)?
> >
> > Just my 2 cents
> > Ravi
> >
> >
> > On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <jd...@hortonworks.com> wrote:
> >
> > > - 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 <vi...@apache.org>
> > > Sent: Monday, June 06, 2016 9:36 PM
> > > To: Andrew Wang
> > > Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org; 
> > > hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; 
> > > yarn-dev@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
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

Re: Why there are so many revert operations on trunk?

[Colin McCabe <cm...@apache.org>]

One anti-pattern that keeps coming up over and over again is people
trying to do big and complex features without feature branches.  This
happened with HDFS truncate as well.  This inevitably leads to
controversy because people see very big and invasive patches zooming
past and get alarmed.  Devops people see complicated new code going
directly into production branches and freak out.  Developers see new
APIs getting added without much discussion and start pushing back.

This all gets worse when it's combined with the lack of an up-to-date
design doc.  This leads to people asking the same questions over and
over, since there's no central place they can go to do background
reading about the new feature.  It also tends to lead to arguments,
since the design decisions that were made seem to come out of nowhere,
rather than being justified by careful consideration of alternatives.

When patches get committed directly to production branches, the
discussion also gets mixed up with release management discussions, which
are often contentious as well.  Release management discussions can go on
for a while at the best of times-- when you combine this with all the
above, it just becomes really messy.

My advice is, if 3 or more people ask you for a feature branch, just
create a feature branch already!  It makes things a lot simpler and less
controversial.  It decouples the feature development discussion from the
release management discussion.  It gives developers the ability to look
at the feature as a whole, rather than feeling like they have to
understand each commit in isolation.  Devops people feel like they can
relax because the decision about what stable branches to backport to
will be made after they have a chance to clearly understand the new
feature, rather than before.  The branch merge email functions as a kind
of overview of the feature which makes people more comfortable with it.

Feature branches actually speed up development for medium or large-sized
features.  You can have branch committers who are not full committers,
but can commit to the branch.  You can rewrite your API at any time
without worrying about compatibility.  You can rewrite the history of
the branch however you like to explore new approaches.  You don't need
to backport each of your patches to N stable branches.

Some people seem scared by the need for a merge vote to merge a feature
branch.  But if your feature is big, you are going to get scrutiny
anyway.  Committing stuff directly to trunk or branch-2 is a not a "get
out of jail free" card that bypasses community review.  If anything,
community review will probably be longer and more contentious because of
the reasons above.  People get frustrated when commits to production
branches continue even while big questions about the feature still
remain unanswered.

We already have rules constraining the use of the -1 vote.  Like any
other discussion, -1 votes need to be "constructive"-- that is, they
need to clearly spell out the way forward, rather than just saying no. 
In this particular case, the concerns we had were about the way the
feature was being developed, and the API.

I think that the discussion that is going on for HDFS async right now is
healthy, and will lead to a better feature.  We have people from
downstream projects such as HBase commenting on the kind of APIs they
would find useful.  We have discussions about the impact on the RPC
system, and the branches that it makes sense to target.  And now that we
have a feature branch, we have a lot more freedom to experiment.

best,
Colin


On Tue, Jun 7, 2016, at 11:02, larry mccay wrote:
> -1 needs not be a taken as a derogatory statement being a number should
> actually make it less emotional.
> It is dangerous to a community to become oversensitive to it.
> 
> I generally see language such as "I am -1 on this until this particular
> thing is fixed" or that it violates some common pattern or precedence set
> in the project. This is perfectly reasonable language and there is no
> reason to make the reviewer provide an alternative.
> 
> So, I am giving my -1 to any proposal for rule changes on -1 votes. :)
> 
> 
> On Tue, Jun 7, 2016 at 1:15 PM, Ravi Prakash <ra...@gmail.com>
> wrote:
> 
> > +1 on being more respectful. We seem to be having a lot of distasteful
> > discussions recently. If we fight each other, we are only helping our
> > competitors win (and trust me, its out there).
> >
> > I would also respectfully request people not to throw -1s around. I have
> > faced this a few times and its really frustrating. Every one has opinions
> > and some times different people can't fathom why someone else thinks the
> > way they do. I am pretty sure none of us is acting with malicious intent,
> > so perhaps a little more tolerance, faith and trust will help all of us
> > improve Hadoop and the ecosystem much faster. That's not to say that
> > sometimes -1s are not warranted, but we should look to it as an extreme
> > measure. Unfortunately there is very little disincentive right now to vote
> > -1 . Maybe we should modify the rules..... if you vote -1 , you have to
> > come up with an alternative implementation? (perhaps limit the amount of
> > time you have to the amount already spent in producing the patch that you
> > are against)?
> >
> > Just my 2 cents
> > Ravi
> >
> >
> > On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <jd...@hortonworks.com> wrote:
> >
> > > - 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 <vi...@apache.org>
> > > Sent: Monday, June 06, 2016 9:36 PM
> > > To: Andrew Wang
> > > Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org;
> > > hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
> > > yarn-dev@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
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

Re: Why there are so many revert operations on trunk?

[Ravi Prakash <ra...@gmail.com>]

Lolz!

Thanks for your opinion Larry. I have often seen "-1 until this is done
according to my way rather than your way" (obviously not in those words),
even when both ways are perfectly reasonable. Anyway, I didn't expect the
voting rules to change. :-)

Cheers
Ravi

On Tue, Jun 7, 2016 at 11:02 AM, larry mccay <la...@gmail.com> wrote:

> -1 needs not be a taken as a derogatory statement being a number should
> actually make it less emotional.
> It is dangerous to a community to become oversensitive to it.
>
> I generally see language such as "I am -1 on this until this particular
> thing is fixed" or that it violates some common pattern or precedence set
> in the project. This is perfectly reasonable language and there is no
> reason to make the reviewer provide an alternative.
>
> So, I am giving my -1 to any proposal for rule changes on -1 votes. :)
>
>
> On Tue, Jun 7, 2016 at 1:15 PM, Ravi Prakash <ra...@gmail.com> wrote:
>
>> +1 on being more respectful. We seem to be having a lot of distasteful
>> discussions recently. If we fight each other, we are only helping our
>> competitors win (and trust me, its out there).
>>
>> I would also respectfully request people not to throw -1s around. I have
>> faced this a few times and its really frustrating. Every one has opinions
>> and some times different people can't fathom why someone else thinks the
>> way they do. I am pretty sure none of us is acting with malicious intent,
>> so perhaps a little more tolerance, faith and trust will help all of us
>> improve Hadoop and the ecosystem much faster. That's not to say that
>> sometimes -1s are not warranted, but we should look to it as an extreme
>> measure. Unfortunately there is very little disincentive right now to vote
>> -1 . Maybe we should modify the rules..... if you vote -1 , you have to
>> come up with an alternative implementation? (perhaps limit the amount of
>> time you have to the amount already spent in producing the patch that you
>> are against)?
>>
>> Just my 2 cents
>> Ravi
>>
>>
>> On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <jd...@hortonworks.com> wrote:
>>
>> > - 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 <vi...@apache.org>
>> > Sent: Monday, June 06, 2016 9:36 PM
>> > To: Andrew Wang
>> > Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org;
>> > hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
>> > yarn-dev@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
>> >
>>
>
>

Re: Why there are so many revert operations on trunk?

[Ravi Prakash <ra...@gmail.com>]

Lolz!

Thanks for your opinion Larry. I have often seen "-1 until this is done
according to my way rather than your way" (obviously not in those words),
even when both ways are perfectly reasonable. Anyway, I didn't expect the
voting rules to change. :-)

Cheers
Ravi

On Tue, Jun 7, 2016 at 11:02 AM, larry mccay <la...@gmail.com> wrote:

> -1 needs not be a taken as a derogatory statement being a number should
> actually make it less emotional.
> It is dangerous to a community to become oversensitive to it.
>
> I generally see language such as "I am -1 on this until this particular
> thing is fixed" or that it violates some common pattern or precedence set
> in the project. This is perfectly reasonable language and there is no
> reason to make the reviewer provide an alternative.
>
> So, I am giving my -1 to any proposal for rule changes on -1 votes. :)
>
>
> On Tue, Jun 7, 2016 at 1:15 PM, Ravi Prakash <ra...@gmail.com> wrote:
>
>> +1 on being more respectful. We seem to be having a lot of distasteful
>> discussions recently. If we fight each other, we are only helping our
>> competitors win (and trust me, its out there).
>>
>> I would also respectfully request people not to throw -1s around. I have
>> faced this a few times and its really frustrating. Every one has opinions
>> and some times different people can't fathom why someone else thinks the
>> way they do. I am pretty sure none of us is acting with malicious intent,
>> so perhaps a little more tolerance, faith and trust will help all of us
>> improve Hadoop and the ecosystem much faster. That's not to say that
>> sometimes -1s are not warranted, but we should look to it as an extreme
>> measure. Unfortunately there is very little disincentive right now to vote
>> -1 . Maybe we should modify the rules..... if you vote -1 , you have to
>> come up with an alternative implementation? (perhaps limit the amount of
>> time you have to the amount already spent in producing the patch that you
>> are against)?
>>
>> Just my 2 cents
>> Ravi
>>
>>
>> On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <jd...@hortonworks.com> wrote:
>>
>> > - 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 <vi...@apache.org>
>> > Sent: Monday, June 06, 2016 9:36 PM
>> > To: Andrew Wang
>> > Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org;
>> > hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
>> > yarn-dev@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
>> >
>>
>
>

Re: Why there are so many revert operations on trunk?

[larry mccay <la...@gmail.com>]

-1 needs not be a taken as a derogatory statement being a number should
actually make it less emotional.
It is dangerous to a community to become oversensitive to it.

I generally see language such as "I am -1 on this until this particular
thing is fixed" or that it violates some common pattern or precedence set
in the project. This is perfectly reasonable language and there is no
reason to make the reviewer provide an alternative.

So, I am giving my -1 to any proposal for rule changes on -1 votes. :)


On Tue, Jun 7, 2016 at 1:15 PM, Ravi Prakash <ra...@gmail.com> wrote:

> +1 on being more respectful. We seem to be having a lot of distasteful
> discussions recently. If we fight each other, we are only helping our
> competitors win (and trust me, its out there).
>
> I would also respectfully request people not to throw -1s around. I have
> faced this a few times and its really frustrating. Every one has opinions
> and some times different people can't fathom why someone else thinks the
> way they do. I am pretty sure none of us is acting with malicious intent,
> so perhaps a little more tolerance, faith and trust will help all of us
> improve Hadoop and the ecosystem much faster. That's not to say that
> sometimes -1s are not warranted, but we should look to it as an extreme
> measure. Unfortunately there is very little disincentive right now to vote
> -1 . Maybe we should modify the rules..... if you vote -1 , you have to
> come up with an alternative implementation? (perhaps limit the amount of
> time you have to the amount already spent in producing the patch that you
> are against)?
>
> Just my 2 cents
> Ravi
>
>
> On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <jd...@hortonworks.com> wrote:
>
> > - 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 <vi...@apache.org>
> > Sent: Monday, June 06, 2016 9:36 PM
> > To: Andrew Wang
> > Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org;
> > hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
> > yarn-dev@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
> >
>

Re: Why there are so many revert operations on trunk?

[larry mccay <la...@gmail.com>]

-1 needs not be a taken as a derogatory statement being a number should
actually make it less emotional.
It is dangerous to a community to become oversensitive to it.

I generally see language such as "I am -1 on this until this particular
thing is fixed" or that it violates some common pattern or precedence set
in the project. This is perfectly reasonable language and there is no
reason to make the reviewer provide an alternative.

So, I am giving my -1 to any proposal for rule changes on -1 votes. :)


On Tue, Jun 7, 2016 at 1:15 PM, Ravi Prakash <ra...@gmail.com> wrote:

> +1 on being more respectful. We seem to be having a lot of distasteful
> discussions recently. If we fight each other, we are only helping our
> competitors win (and trust me, its out there).
>
> I would also respectfully request people not to throw -1s around. I have
> faced this a few times and its really frustrating. Every one has opinions
> and some times different people can't fathom why someone else thinks the
> way they do. I am pretty sure none of us is acting with malicious intent,
> so perhaps a little more tolerance, faith and trust will help all of us
> improve Hadoop and the ecosystem much faster. That's not to say that
> sometimes -1s are not warranted, but we should look to it as an extreme
> measure. Unfortunately there is very little disincentive right now to vote
> -1 . Maybe we should modify the rules..... if you vote -1 , you have to
> come up with an alternative implementation? (perhaps limit the amount of
> time you have to the amount already spent in producing the patch that you
> are against)?
>
> Just my 2 cents
> Ravi
>
>
> On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <jd...@hortonworks.com> wrote:
>
> > - 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 <vi...@apache.org>
> > Sent: Monday, June 06, 2016 9:36 PM
> > To: Andrew Wang
> > Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org;
> > hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
> > yarn-dev@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
> >
>

Re: Why there are so many revert operations on trunk?

[larry mccay <la...@gmail.com>]

-1 needs not be a taken as a derogatory statement being a number should
actually make it less emotional.
It is dangerous to a community to become oversensitive to it.

I generally see language such as "I am -1 on this until this particular
thing is fixed" or that it violates some common pattern or precedence set
in the project. This is perfectly reasonable language and there is no
reason to make the reviewer provide an alternative.

So, I am giving my -1 to any proposal for rule changes on -1 votes. :)


On Tue, Jun 7, 2016 at 1:15 PM, Ravi Prakash <ra...@gmail.com> wrote:

> +1 on being more respectful. We seem to be having a lot of distasteful
> discussions recently. If we fight each other, we are only helping our
> competitors win (and trust me, its out there).
>
> I would also respectfully request people not to throw -1s around. I have
> faced this a few times and its really frustrating. Every one has opinions
> and some times different people can't fathom why someone else thinks the
> way they do. I am pretty sure none of us is acting with malicious intent,
> so perhaps a little more tolerance, faith and trust will help all of us
> improve Hadoop and the ecosystem much faster. That's not to say that
> sometimes -1s are not warranted, but we should look to it as an extreme
> measure. Unfortunately there is very little disincentive right now to vote
> -1 . Maybe we should modify the rules..... if you vote -1 , you have to
> come up with an alternative implementation? (perhaps limit the amount of
> time you have to the amount already spent in producing the patch that you
> are against)?
>
> Just my 2 cents
> Ravi
>
>
> On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <jd...@hortonworks.com> wrote:
>
> > - 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 <vi...@apache.org>
> > Sent: Monday, June 06, 2016 9:36 PM
> > To: Andrew Wang
> > Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org;
> > hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
> > yarn-dev@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
> >
>

Re: Why there are so many revert operations on trunk?

[larry mccay <la...@gmail.com>]

-1 needs not be a taken as a derogatory statement being a number should
actually make it less emotional.
It is dangerous to a community to become oversensitive to it.

I generally see language such as "I am -1 on this until this particular
thing is fixed" or that it violates some common pattern or precedence set
in the project. This is perfectly reasonable language and there is no
reason to make the reviewer provide an alternative.

So, I am giving my -1 to any proposal for rule changes on -1 votes. :)


On Tue, Jun 7, 2016 at 1:15 PM, Ravi Prakash <ra...@gmail.com> wrote:

> +1 on being more respectful. We seem to be having a lot of distasteful
> discussions recently. If we fight each other, we are only helping our
> competitors win (and trust me, its out there).
>
> I would also respectfully request people not to throw -1s around. I have
> faced this a few times and its really frustrating. Every one has opinions
> and some times different people can't fathom why someone else thinks the
> way they do. I am pretty sure none of us is acting with malicious intent,
> so perhaps a little more tolerance, faith and trust will help all of us
> improve Hadoop and the ecosystem much faster. That's not to say that
> sometimes -1s are not warranted, but we should look to it as an extreme
> measure. Unfortunately there is very little disincentive right now to vote
> -1 . Maybe we should modify the rules..... if you vote -1 , you have to
> come up with an alternative implementation? (perhaps limit the amount of
> time you have to the amount already spent in producing the patch that you
> are against)?
>
> Just my 2 cents
> Ravi
>
>
> On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <jd...@hortonworks.com> wrote:
>
> > - 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 <vi...@apache.org>
> > Sent: Monday, June 06, 2016 9:36 PM
> > To: Andrew Wang
> > Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org;
> > hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
> > yarn-dev@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
> >
>

Re: Why there are so many revert operations on trunk?

[Ravi Prakash <ra...@gmail.com>]

+1 on being more respectful. We seem to be having a lot of distasteful
discussions recently. If we fight each other, we are only helping our
competitors win (and trust me, its out there).

I would also respectfully request people not to throw -1s around. I have
faced this a few times and its really frustrating. Every one has opinions
and some times different people can't fathom why someone else thinks the
way they do. I am pretty sure none of us is acting with malicious intent,
so perhaps a little more tolerance, faith and trust will help all of us
improve Hadoop and the ecosystem much faster. That's not to say that
sometimes -1s are not warranted, but we should look to it as an extreme
measure. Unfortunately there is very little disincentive right now to vote
-1 . Maybe we should modify the rules..... if you vote -1 , you have to
come up with an alternative implementation? (perhaps limit the amount of
time you have to the amount already spent in producing the patch that you
are against)?

Just my 2 cents
Ravi


On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <jd...@hortonworks.com> wrote:

> - 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 <vi...@apache.org>
> Sent: Monday, June 06, 2016 9:36 PM
> To: Andrew Wang
> Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org;
> hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
> yarn-dev@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
>

Re: Why there are so many revert operations on trunk?

[Ravi Prakash <ra...@gmail.com>]

+1 on being more respectful. We seem to be having a lot of distasteful
discussions recently. If we fight each other, we are only helping our
competitors win (and trust me, its out there).

I would also respectfully request people not to throw -1s around. I have
faced this a few times and its really frustrating. Every one has opinions
and some times different people can't fathom why someone else thinks the
way they do. I am pretty sure none of us is acting with malicious intent,
so perhaps a little more tolerance, faith and trust will help all of us
improve Hadoop and the ecosystem much faster. That's not to say that
sometimes -1s are not warranted, but we should look to it as an extreme
measure. Unfortunately there is very little disincentive right now to vote
-1 . Maybe we should modify the rules..... if you vote -1 , you have to
come up with an alternative implementation? (perhaps limit the amount of
time you have to the amount already spent in producing the patch that you
are against)?

Just my 2 cents
Ravi


On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <jd...@hortonworks.com> wrote:

> - 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 <vi...@apache.org>
> Sent: Monday, June 06, 2016 9:36 PM
> To: Andrew Wang
> Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org;
> hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
> yarn-dev@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
>

Re: Why there are so many revert operations on trunk?

[Ravi Prakash <ra...@gmail.com>]

+1 on being more respectful. We seem to be having a lot of distasteful
discussions recently. If we fight each other, we are only helping our
competitors win (and trust me, its out there).

I would also respectfully request people not to throw -1s around. I have
faced this a few times and its really frustrating. Every one has opinions
and some times different people can't fathom why someone else thinks the
way they do. I am pretty sure none of us is acting with malicious intent,
so perhaps a little more tolerance, faith and trust will help all of us
improve Hadoop and the ecosystem much faster. That's not to say that
sometimes -1s are not warranted, but we should look to it as an extreme
measure. Unfortunately there is very little disincentive right now to vote
-1 . Maybe we should modify the rules..... if you vote -1 , you have to
come up with an alternative implementation? (perhaps limit the amount of
time you have to the amount already spent in producing the patch that you
are against)?

Just my 2 cents
Ravi


On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <jd...@hortonworks.com> wrote:

> - 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 <vi...@apache.org>
> Sent: Monday, June 06, 2016 9:36 PM
> To: Andrew Wang
> Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org;
> hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
> yarn-dev@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
>

Re: Why there are so many revert operations on trunk?

[Ravi Prakash <ra...@gmail.com>]

+1 on being more respectful. We seem to be having a lot of distasteful
discussions recently. If we fight each other, we are only helping our
competitors win (and trust me, its out there).

I would also respectfully request people not to throw -1s around. I have
faced this a few times and its really frustrating. Every one has opinions
and some times different people can't fathom why someone else thinks the
way they do. I am pretty sure none of us is acting with malicious intent,
so perhaps a little more tolerance, faith and trust will help all of us
improve Hadoop and the ecosystem much faster. That's not to say that
sometimes -1s are not warranted, but we should look to it as an extreme
measure. Unfortunately there is very little disincentive right now to vote
-1 . Maybe we should modify the rules..... if you vote -1 , you have to
come up with an alternative implementation? (perhaps limit the amount of
time you have to the amount already spent in producing the patch that you
are against)?

Just my 2 cents
Ravi


On Tue, Jun 7, 2016 at 7:54 AM, Junping Du <jd...@hortonworks.com> wrote:

> - 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 <vi...@apache.org>
> Sent: Monday, June 06, 2016 9:36 PM
> To: Andrew Wang
> Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org;
> hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
> yarn-dev@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
>

Re: Why there are so many revert operations on trunk?

[Junping Du <jd...@hortonworks.com>]

- 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 <vi...@apache.org>
Sent: Monday, June 06, 2016 9:36 PM
To: Andrew Wang
Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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

Re: Why there are so many revert operations on trunk?

[Junping Du <jd...@hortonworks.com>]

- 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 <vi...@apache.org>
Sent: Monday, June 06, 2016 9:36 PM
To: Andrew Wang
Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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

Re: Why there are so many revert operations on trunk?

[Steve Loughran <st...@hortonworks.com>]

+1

This is a good summary, And we are better off resolving issues through discussions on emails, rather than JIRA, and everyone behaving amicably towards each other.


I think we should be more willing to do feature branches, especially for things like

- anything deep into the codebase
- self-contained things
-something that will be a series of incremental patches, each with no real benefit on their own. That is: things where adding to the codebase is, until complete, only a risk of regressions. 

If yetus doesn't do preflight checks on feature branches, we can get that in, and set up Jenkins nightly builds for the branches too (With different email policies: email to committers & select listeners, not more noise on the deve lists)



Regarding where we are today

I don't know what can/should be done with the set of patches that just got moved to a feature branch, except that Vinods "not in 2.8" veto holds there. As, presumably, does Andrew's "not in 3.0 alpha without a Java 8 API"

Which means that any API which gets in a Java-7 compatible Hadoop release (2.9?) will have to be on an API which we know won't last.

1. I propose adding a new stability state/tag, @Experimental, to warn users that this not only "may" go away, but is in fact highly likely to, and any replacement may need big code changes. The @Unstable tag has been devalued for this from its near-universalness: you see the tag and ignore it.

2. Any proposed API for branch-2 must be tagged @Experimental, put that in the name of the API ( that is, not, say AsyncFileSystem, but ExperimentalAsyncDelete}} or similar.

4. The long-term API is going to be: Java 8, strictly specified by a whole new section in the FS API (yes, that is where my veto would come in. No spec, no tests: no commit). The tests will be at part of the Abstract contract test suite, and, ideally, backed with another implementation alongside that of HDFS. This could just be a thread-pooled thing working with a normal sync FS.

5. People who intend to use the Async API —Hive, HBase, etc, get involved in that process, ideally seeing how well they could get a branch of their own code to work with the API. That would be a validation of the API itself, identify and force the clarification of any ambiguities, etc.

(4) + (5) may seem expensive/slow, but if HBase and Hive dev teams are involved, it means that what eventually gets into Hadoop is ready to backed by code downstream.

I'm not going to get involved here, except to warn that I will be reviewing the markdown specification stuff. I'll help: people might want to help review the listFiles and listStatus operations which I sat down to define recently: https://issues.apache.org/jira/browse/HADOOP-13207




> On 6 Jun 2016, at 22:36, Vinod Kumar Vavilapalli <vi...@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.
> 
> 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.
> 
>> * 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

Re: Why there are so many revert operations on trunk?

[Junping Du <jd...@hortonworks.com>]

- 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 <vi...@apache.org>
Sent: Monday, June 06, 2016 9:36 PM
To: Andrew Wang
Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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

Re: Why there are so many revert operations on trunk?

[Steve Loughran <st...@hortonworks.com>]

+1

This is a good summary, And we are better off resolving issues through discussions on emails, rather than JIRA, and everyone behaving amicably towards each other.


I think we should be more willing to do feature branches, especially for things like

- anything deep into the codebase
- self-contained things
-something that will be a series of incremental patches, each with no real benefit on their own. That is: things where adding to the codebase is, until complete, only a risk of regressions. 

If yetus doesn't do preflight checks on feature branches, we can get that in, and set up Jenkins nightly builds for the branches too (With different email policies: email to committers & select listeners, not more noise on the deve lists)



Regarding where we are today

I don't know what can/should be done with the set of patches that just got moved to a feature branch, except that Vinods "not in 2.8" veto holds there. As, presumably, does Andrew's "not in 3.0 alpha without a Java 8 API"

Which means that any API which gets in a Java-7 compatible Hadoop release (2.9?) will have to be on an API which we know won't last.

1. I propose adding a new stability state/tag, @Experimental, to warn users that this not only "may" go away, but is in fact highly likely to, and any replacement may need big code changes. The @Unstable tag has been devalued for this from its near-universalness: you see the tag and ignore it.

2. Any proposed API for branch-2 must be tagged @Experimental, put that in the name of the API ( that is, not, say AsyncFileSystem, but ExperimentalAsyncDelete}} or similar.

4. The long-term API is going to be: Java 8, strictly specified by a whole new section in the FS API (yes, that is where my veto would come in. No spec, no tests: no commit). The tests will be at part of the Abstract contract test suite, and, ideally, backed with another implementation alongside that of HDFS. This could just be a thread-pooled thing working with a normal sync FS.

5. People who intend to use the Async API —Hive, HBase, etc, get involved in that process, ideally seeing how well they could get a branch of their own code to work with the API. That would be a validation of the API itself, identify and force the clarification of any ambiguities, etc.

(4) + (5) may seem expensive/slow, but if HBase and Hive dev teams are involved, it means that what eventually gets into Hadoop is ready to backed by code downstream.

I'm not going to get involved here, except to warn that I will be reviewing the markdown specification stuff. I'll help: people might want to help review the listFiles and listStatus operations which I sat down to define recently: https://issues.apache.org/jira/browse/HADOOP-13207




> On 6 Jun 2016, at 22:36, Vinod Kumar Vavilapalli <vi...@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.
> 
> 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.
> 
>> * 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

Re: Why there are so many revert operations on trunk?

[Steve Loughran <st...@hortonworks.com>]

+1

This is a good summary, And we are better off resolving issues through discussions on emails, rather than JIRA, and everyone behaving amicably towards each other.


I think we should be more willing to do feature branches, especially for things like

- anything deep into the codebase
- self-contained things
-something that will be a series of incremental patches, each with no real benefit on their own. That is: things where adding to the codebase is, until complete, only a risk of regressions. 

If yetus doesn't do preflight checks on feature branches, we can get that in, and set up Jenkins nightly builds for the branches too (With different email policies: email to committers & select listeners, not more noise on the deve lists)



Regarding where we are today

I don't know what can/should be done with the set of patches that just got moved to a feature branch, except that Vinods "not in 2.8" veto holds there. As, presumably, does Andrew's "not in 3.0 alpha without a Java 8 API"

Which means that any API which gets in a Java-7 compatible Hadoop release (2.9?) will have to be on an API which we know won't last.

1. I propose adding a new stability state/tag, @Experimental, to warn users that this not only "may" go away, but is in fact highly likely to, and any replacement may need big code changes. The @Unstable tag has been devalued for this from its near-universalness: you see the tag and ignore it.

2. Any proposed API for branch-2 must be tagged @Experimental, put that in the name of the API ( that is, not, say AsyncFileSystem, but ExperimentalAsyncDelete}} or similar.

4. The long-term API is going to be: Java 8, strictly specified by a whole new section in the FS API (yes, that is where my veto would come in. No spec, no tests: no commit). The tests will be at part of the Abstract contract test suite, and, ideally, backed with another implementation alongside that of HDFS. This could just be a thread-pooled thing working with a normal sync FS.

5. People who intend to use the Async API —Hive, HBase, etc, get involved in that process, ideally seeing how well they could get a branch of their own code to work with the API. That would be a validation of the API itself, identify and force the clarification of any ambiguities, etc.

(4) + (5) may seem expensive/slow, but if HBase and Hive dev teams are involved, it means that what eventually gets into Hadoop is ready to backed by code downstream.

I'm not going to get involved here, except to warn that I will be reviewing the markdown specification stuff. I'll help: people might want to help review the listFiles and listStatus operations which I sat down to define recently: https://issues.apache.org/jira/browse/HADOOP-13207




> On 6 Jun 2016, at 22:36, Vinod Kumar Vavilapalli <vi...@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.
> 
> 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.
> 
>> * 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

Re: Why there are so many revert operations on trunk?

[Junping Du <jd...@hortonworks.com>]

- 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 <vi...@apache.org>
Sent: Monday, June 06, 2016 9:36 PM
To: Andrew Wang
Cc: Junping Du; Aaron T. Myers; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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

Re: Why there are so many revert operations on trunk?

[Steve Loughran <st...@hortonworks.com>]

+1

This is a good summary, And we are better off resolving issues through discussions on emails, rather than JIRA, and everyone behaving amicably towards each other.


I think we should be more willing to do feature branches, especially for things like

- anything deep into the codebase
- self-contained things
-something that will be a series of incremental patches, each with no real benefit on their own. That is: things where adding to the codebase is, until complete, only a risk of regressions. 

If yetus doesn't do preflight checks on feature branches, we can get that in, and set up Jenkins nightly builds for the branches too (With different email policies: email to committers & select listeners, not more noise on the deve lists)



Regarding where we are today

I don't know what can/should be done with the set of patches that just got moved to a feature branch, except that Vinods "not in 2.8" veto holds there. As, presumably, does Andrew's "not in 3.0 alpha without a Java 8 API"

Which means that any API which gets in a Java-7 compatible Hadoop release (2.9?) will have to be on an API which we know won't last.

1. I propose adding a new stability state/tag, @Experimental, to warn users that this not only "may" go away, but is in fact highly likely to, and any replacement may need big code changes. The @Unstable tag has been devalued for this from its near-universalness: you see the tag and ignore it.

2. Any proposed API for branch-2 must be tagged @Experimental, put that in the name of the API ( that is, not, say AsyncFileSystem, but ExperimentalAsyncDelete}} or similar.

4. The long-term API is going to be: Java 8, strictly specified by a whole new section in the FS API (yes, that is where my veto would come in. No spec, no tests: no commit). The tests will be at part of the Abstract contract test suite, and, ideally, backed with another implementation alongside that of HDFS. This could just be a thread-pooled thing working with a normal sync FS.

5. People who intend to use the Async API —Hive, HBase, etc, get involved in that process, ideally seeing how well they could get a branch of their own code to work with the API. That would be a validation of the API itself, identify and force the clarification of any ambiguities, etc.

(4) + (5) may seem expensive/slow, but if HBase and Hive dev teams are involved, it means that what eventually gets into Hadoop is ready to backed by code downstream.

I'm not going to get involved here, except to warn that I will be reviewing the markdown specification stuff. I'll help: people might want to help review the listFiles and listStatus operations which I sat down to define recently: https://issues.apache.org/jira/browse/HADOOP-13207




> On 6 Jun 2016, at 22:36, Vinod Kumar Vavilapalli <vi...@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.
> 
> 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.
> 
>> * 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

Re: Why there are so many revert operations on trunk?

[larry mccay <lm...@apache.org>]

inline....


On Mon, Jun 6, 2016 at 4:36 PM, Vinod Kumar Vavilapalli <vi...@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

Re: Why there are so many revert operations on trunk?

[larry mccay <lm...@apache.org>]

inline....


On Mon, Jun 6, 2016 at 4:36 PM, Vinod Kumar Vavilapalli <vi...@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

Re: Why there are so many revert operations on trunk?

[larry mccay <lm...@apache.org>]

inline....


On Mon, Jun 6, 2016 at 4:36 PM, Vinod Kumar Vavilapalli <vi...@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

Re: Why there are so many revert operations on trunk?

[Vinod Kumar Vavilapalli <vi...@apache.org>]

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 <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

Re: Why there are so many revert operations on trunk?

[larry mccay <lm...@apache.org>]

This seems like something that is going to probably happen again if we
continue to cut releases from trunk.
I know that this has been discussed at length in a separate thread but I
think it would be good to recognize that it is the core of the issue here.

Either we:

* need to define what will happen on trunk in such circumstances and
clearly communicate an action before taking it on the dev@ list or
* we need to not introduce this sort of thrashing on trunk by releasing
from it directly

My humble 2 cents...

--larry


On Mon, Jun 6, 2016 at 1:56 PM, Andrew Wang <an...@cloudera.com>
wrote:

> To clarify what happened here, I moved the commits to a feature branch, not
> just reverting the commits. The intent was to make it easy to merge back in
> later, and also to unblock the 2.8 and 3.0 releases we've been trying very
> hard to wrap up for weeks. This doesn't slow down development since you can
> keep committing to a branch, and I did the git work to make it easy to
> merge back in alter. I'm also happy to review the merge if the concern is
> getting three +1s.
>
> In the comments on HDFS-9924, you can see comments from a month ago raising
> concerns about the API and also that this significant expansion of the HDFS
> API is being done on release branches. There is an explicit -1 on continued
> commits to trunk, and a request to move the commits to a feature branch.
> Similar concerns have been raised by multiple contributors on that JIRA.
> Yet, the commits remained in release branches, and new patches continued to
> be committed to release branches.
>
> There's no need to attribute malicious intent to slow down feature
> development; for some reason I keep seeing this accusation thrown around
> when there are many people chiming in on HDFS-9924 with concerns about the
> feature. Considering how it's expanding the HDFS API, this is also the kind
> of work that should go through a merge vote anyway to get more eyes on it.
>
> We've been converging on the API requirements, but until the user-facing
> API is ready, I don't see the advantage of having this code in a release
> branch. As noted by the contributors on this JIRA, it's new separate code,
> so there's little to no overhead to keeping a feature branch in sync.
>
> So, to sum it up, I moved these commits to a branch because:
>
> * The discussion about the user API is still ongoing, and there is
> currently no user-facing API
> * We are very late in the 2.8 and 3.0 release cycles, trying to do blocker
> burndown
> * This code is separate and thus easy to keep in sync on a branch and merge
> in later
> * 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.
>
> Thanks,
> Andrew
>

Re: Why there are so many revert operations on trunk?

[Vinod Kumar Vavilapalli <vi...@apache.org>]

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 <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

Re: Why there are so many revert operations on trunk?

[Vinod Kumar Vavilapalli <vi...@apache.org>]

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 <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

Re: Why there are so many revert operations on trunk?

[larry mccay <lm...@apache.org>]

This seems like something that is going to probably happen again if we
continue to cut releases from trunk.
I know that this has been discussed at length in a separate thread but I
think it would be good to recognize that it is the core of the issue here.

Either we:

* need to define what will happen on trunk in such circumstances and
clearly communicate an action before taking it on the dev@ list or
* we need to not introduce this sort of thrashing on trunk by releasing
from it directly

My humble 2 cents...

--larry


On Mon, Jun 6, 2016 at 1:56 PM, Andrew Wang <an...@cloudera.com>
wrote:

> To clarify what happened here, I moved the commits to a feature branch, not
> just reverting the commits. The intent was to make it easy to merge back in
> later, and also to unblock the 2.8 and 3.0 releases we've been trying very
> hard to wrap up for weeks. This doesn't slow down development since you can
> keep committing to a branch, and I did the git work to make it easy to
> merge back in alter. I'm also happy to review the merge if the concern is
> getting three +1s.
>
> In the comments on HDFS-9924, you can see comments from a month ago raising
> concerns about the API and also that this significant expansion of the HDFS
> API is being done on release branches. There is an explicit -1 on continued
> commits to trunk, and a request to move the commits to a feature branch.
> Similar concerns have been raised by multiple contributors on that JIRA.
> Yet, the commits remained in release branches, and new patches continued to
> be committed to release branches.
>
> There's no need to attribute malicious intent to slow down feature
> development; for some reason I keep seeing this accusation thrown around
> when there are many people chiming in on HDFS-9924 with concerns about the
> feature. Considering how it's expanding the HDFS API, this is also the kind
> of work that should go through a merge vote anyway to get more eyes on it.
>
> We've been converging on the API requirements, but until the user-facing
> API is ready, I don't see the advantage of having this code in a release
> branch. As noted by the contributors on this JIRA, it's new separate code,
> so there's little to no overhead to keeping a feature branch in sync.
>
> So, to sum it up, I moved these commits to a branch because:
>
> * The discussion about the user API is still ongoing, and there is
> currently no user-facing API
> * We are very late in the 2.8 and 3.0 release cycles, trying to do blocker
> burndown
> * This code is separate and thus easy to keep in sync on a branch and merge
> in later
> * 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.
>
> Thanks,
> Andrew
>

Re: Why there are so many revert operations on trunk?

[Vinod Kumar Vavilapalli <vi...@apache.org>]

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 <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

Re: Why there are so many revert operations on trunk?

[Andrew Wang <an...@cloudera.com>]

To clarify what happened here, I moved the commits to a feature branch, not
just reverting the commits. The intent was to make it easy to merge back in
later, and also to unblock the 2.8 and 3.0 releases we've been trying very
hard to wrap up for weeks. This doesn't slow down development since you can
keep committing to a branch, and I did the git work to make it easy to
merge back in alter. I'm also happy to review the merge if the concern is
getting three +1s.

In the comments on HDFS-9924, you can see comments from a month ago raising
concerns about the API and also that this significant expansion of the HDFS
API is being done on release branches. There is an explicit -1 on continued
commits to trunk, and a request to move the commits to a feature branch.
Similar concerns have been raised by multiple contributors on that JIRA.
Yet, the commits remained in release branches, and new patches continued to
be committed to release branches.

There's no need to attribute malicious intent to slow down feature
development; for some reason I keep seeing this accusation thrown around
when there are many people chiming in on HDFS-9924 with concerns about the
feature. Considering how it's expanding the HDFS API, this is also the kind
of work that should go through a merge vote anyway to get more eyes on it.

We've been converging on the API requirements, but until the user-facing
API is ready, I don't see the advantage of having this code in a release
branch. As noted by the contributors on this JIRA, it's new separate code,
so there's little to no overhead to keeping a feature branch in sync.

So, to sum it up, I moved these commits to a branch because:

* The discussion about the user API is still ongoing, and there is
currently no user-facing API
* We are very late in the 2.8 and 3.0 release cycles, trying to do blocker
burndown
* This code is separate and thus easy to keep in sync on a branch and merge
in later
* 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.

Thanks,
Andrew

Re: Why there are so many revert operations on trunk?

[Jitendra Pandey <ji...@hortonworks.com>]

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 <cd...@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 <jd...@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 <at...@cloudera.com>
>> Sent: Monday, June 06, 2016 4:46 PM
>> To: Junping Du
>> Cc: Andrew Wang; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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 <jd...@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-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

Re: Why there are so many revert operations on trunk?

[Jitendra Pandey <ji...@hortonworks.com>]

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 <cd...@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 <jd...@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 <at...@cloudera.com>
>> Sent: Monday, June 06, 2016 4:46 PM
>> To: Junping Du
>> Cc: Andrew Wang; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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 <jd...@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-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org

Re: Why there are so many revert operations on trunk?

[Jitendra Pandey <ji...@hortonworks.com>]

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 <cd...@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 <jd...@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 <at...@cloudera.com>
>> Sent: Monday, June 06, 2016 4:46 PM
>> To: Junping Du
>> Cc: Andrew Wang; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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 <jd...@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-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

Re: Why there are so many revert operations on trunk?

[Jitendra Pandey <ji...@hortonworks.com>]

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 <cd...@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 <jd...@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 <at...@cloudera.com>
>> Sent: Monday, June 06, 2016 4:46 PM
>> To: Junping Du
>> Cc: Andrew Wang; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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 <jd...@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-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org

Re: Why there are so many revert operations on trunk?

[Chris Douglas <cd...@apache.org>]

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 <jd...@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 <at...@cloudera.com>
> Sent: Monday, June 06, 2016 4:46 PM
> To: Junping Du
> Cc: Andrew Wang; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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 <jd...@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: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

Re: Why there are so many revert operations on trunk?

[Andrew Wang <an...@cloudera.com>]

To clarify what happened here, I moved the commits to a feature branch, not
just reverting the commits. The intent was to make it easy to merge back in
later, and also to unblock the 2.8 and 3.0 releases we've been trying very
hard to wrap up for weeks. This doesn't slow down development since you can
keep committing to a branch, and I did the git work to make it easy to
merge back in alter. I'm also happy to review the merge if the concern is
getting three +1s.

In the comments on HDFS-9924, you can see comments from a month ago raising
concerns about the API and also that this significant expansion of the HDFS
API is being done on release branches. There is an explicit -1 on continued
commits to trunk, and a request to move the commits to a feature branch.
Similar concerns have been raised by multiple contributors on that JIRA.
Yet, the commits remained in release branches, and new patches continued to
be committed to release branches.

There's no need to attribute malicious intent to slow down feature
development; for some reason I keep seeing this accusation thrown around
when there are many people chiming in on HDFS-9924 with concerns about the
feature. Considering how it's expanding the HDFS API, this is also the kind
of work that should go through a merge vote anyway to get more eyes on it.

We've been converging on the API requirements, but until the user-facing
API is ready, I don't see the advantage of having this code in a release
branch. As noted by the contributors on this JIRA, it's new separate code,
so there's little to no overhead to keeping a feature branch in sync.

So, to sum it up, I moved these commits to a branch because:

* The discussion about the user API is still ongoing, and there is
currently no user-facing API
* We are very late in the 2.8 and 3.0 release cycles, trying to do blocker
burndown
* This code is separate and thus easy to keep in sync on a branch and merge
in later
* 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.

Thanks,
Andrew

Re: Why there are so many revert operations on trunk?

[Chris Douglas <cd...@apache.org>]

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 <jd...@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 <at...@cloudera.com>
> Sent: Monday, June 06, 2016 4:46 PM
> To: Junping Du
> Cc: Andrew Wang; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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 <jd...@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: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

Re: Why there are so many revert operations on trunk?

[Chris Douglas <cd...@apache.org>]

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 <jd...@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 <at...@cloudera.com>
> Sent: Monday, June 06, 2016 4:46 PM
> To: Junping Du
> Cc: Andrew Wang; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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 <jd...@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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org

Re: Why there are so many revert operations on trunk?

[Andrew Wang <an...@cloudera.com>]

To clarify what happened here, I moved the commits to a feature branch, not
just reverting the commits. The intent was to make it easy to merge back in
later, and also to unblock the 2.8 and 3.0 releases we've been trying very
hard to wrap up for weeks. This doesn't slow down development since you can
keep committing to a branch, and I did the git work to make it easy to
merge back in alter. I'm also happy to review the merge if the concern is
getting three +1s.

In the comments on HDFS-9924, you can see comments from a month ago raising
concerns about the API and also that this significant expansion of the HDFS
API is being done on release branches. There is an explicit -1 on continued
commits to trunk, and a request to move the commits to a feature branch.
Similar concerns have been raised by multiple contributors on that JIRA.
Yet, the commits remained in release branches, and new patches continued to
be committed to release branches.

There's no need to attribute malicious intent to slow down feature
development; for some reason I keep seeing this accusation thrown around
when there are many people chiming in on HDFS-9924 with concerns about the
feature. Considering how it's expanding the HDFS API, this is also the kind
of work that should go through a merge vote anyway to get more eyes on it.

We've been converging on the API requirements, but until the user-facing
API is ready, I don't see the advantage of having this code in a release
branch. As noted by the contributors on this JIRA, it's new separate code,
so there's little to no overhead to keeping a feature branch in sync.

So, to sum it up, I moved these commits to a branch because:

* The discussion about the user API is still ongoing, and there is
currently no user-facing API
* We are very late in the 2.8 and 3.0 release cycles, trying to do blocker
burndown
* This code is separate and thus easy to keep in sync on a branch and merge
in later
* 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.

Thanks,
Andrew

Re: Why there are so many revert operations on trunk?

[Chris Douglas <cd...@apache.org>]

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 <jd...@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 <at...@cloudera.com>
> Sent: Monday, June 06, 2016 4:46 PM
> To: Junping Du
> Cc: Andrew Wang; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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 <jd...@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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org

Re: Why there are so many revert operations on trunk?

[Andrew Wang <an...@cloudera.com>]

To clarify what happened here, I moved the commits to a feature branch, not
just reverting the commits. The intent was to make it easy to merge back in
later, and also to unblock the 2.8 and 3.0 releases we've been trying very
hard to wrap up for weeks. This doesn't slow down development since you can
keep committing to a branch, and I did the git work to make it easy to
merge back in alter. I'm also happy to review the merge if the concern is
getting three +1s.

In the comments on HDFS-9924, you can see comments from a month ago raising
concerns about the API and also that this significant expansion of the HDFS
API is being done on release branches. There is an explicit -1 on continued
commits to trunk, and a request to move the commits to a feature branch.
Similar concerns have been raised by multiple contributors on that JIRA.
Yet, the commits remained in release branches, and new patches continued to
be committed to release branches.

There's no need to attribute malicious intent to slow down feature
development; for some reason I keep seeing this accusation thrown around
when there are many people chiming in on HDFS-9924 with concerns about the
feature. Considering how it's expanding the HDFS API, this is also the kind
of work that should go through a merge vote anyway to get more eyes on it.

We've been converging on the API requirements, but until the user-facing
API is ready, I don't see the advantage of having this code in a release
branch. As noted by the contributors on this JIRA, it's new separate code,
so there's little to no overhead to keeping a feature branch in sync.

So, to sum it up, I moved these commits to a branch because:

* The discussion about the user API is still ongoing, and there is
currently no user-facing API
* We are very late in the 2.8 and 3.0 release cycles, trying to do blocker
burndown
* This code is separate and thus easy to keep in sync on a branch and merge
in later
* 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.

Thanks,
Andrew

Re: Why there are so many revert operations on trunk?

[Junping Du <jd...@hortonworks.com>]

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 <at...@cloudera.com>
Sent: Monday, June 06, 2016 4:46 PM
To: Junping Du
Cc: Andrew Wang; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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 <jd...@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

Re: Why there are so many revert operations on trunk?

[Junping Du <jd...@hortonworks.com>]

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 <at...@cloudera.com>
Sent: Monday, June 06, 2016 4:46 PM
To: Junping Du
Cc: Andrew Wang; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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 <jd...@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

Re: Why there are so many revert operations on trunk?

[Junping Du <jd...@hortonworks.com>]

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 <at...@cloudera.com>
Sent: Monday, June 06, 2016 4:46 PM
To: Junping Du
Cc: Andrew Wang; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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 <jd...@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

Re: Why there are so many revert operations on trunk?

[Junping Du <jd...@hortonworks.com>]

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 <at...@cloudera.com>
Sent: Monday, June 06, 2016 4:46 PM
To: Junping Du
Cc: Andrew Wang; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@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 <jd...@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

Re: Why there are so many revert operations on trunk?

["Aaron T. Myers" <at...@cloudera.com>]

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 <jd...@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
>

Re: Why there are so many revert operations on trunk?

["Aaron T. Myers" <at...@cloudera.com>]

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 <jd...@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
>

Re: Why there are so many revert operations on trunk?

["Aaron T. Myers" <at...@cloudera.com>]

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 <jd...@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
>

Re: Why there are so many revert operations on trunk?

["Aaron T. Myers" <at...@cloudera.com>]

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 <jd...@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
>