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

[Ravi Prakash]

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  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  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  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 
>> > Sent: Monday, June 06, 2016 9:36 PM
>> > To: Andrew Wang
>> > Cc: Junping Du; Aaron T. Myers; common-...@hadoop.apache.org;
>> > hdfs-...@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
>> > yarn-...@hadoop.apache.org
>> > Subject: Re: Why there are so many revert operations on trunk?
>> >
>> > 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 

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

[larry mccay]

-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  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  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 
> > Sent: Monday, June 06, 2016 9:36 PM
> > To: Andrew Wang
> > Cc: Junping Du; Aaron T. Myers; common-...@hadoop.apache.org;
> > hdfs-...@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
> > yarn-...@hadoop.apache.org
> > Subject: Re: Why there are so many revert operations on trunk?
> >
> > 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.
> 

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

[Ravi Prakash]

+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  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 
> Sent: Monday, June 06, 2016 9:36 PM
> To: Andrew Wang
> Cc: Junping Du; Aaron T. Myers; common-...@hadoop.apache.org;
> hdfs-...@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
> yarn-...@hadoop.apache.org
> Subject: Re: Why there are so many revert operations on trunk?
>
> 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 

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

[Junping Du]

- 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 
Sent: Monday, June 06, 2016 9:36 PM
To: Andrew Wang
Cc: Junping Du; Aaron T. Myers; common-...@hadoop.apache.org; 
hdfs-...@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; 
yarn-...@hadoop.apache.org
Subject: Re: Why there are so many revert operations on trunk?

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]

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

Apache Hadoop qbt Report: trunk+JDK8 on Linux/x86

[Apache Jenkins Server]

For more details, see 
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/50/

[Jun 6, 2016 8:28:21 AM] (szetszwo) Revert "Revert "HDFS-10224. Implement 
asynchronous rename for
[Jun 6, 2016 8:28:47 AM] (szetszwo) Revert "Revert "HADOOP-12957. Limit the 
number of outstanding async
[Jun 6, 2016 8:29:38 AM] (szetszwo) Revert "Revert "HDFS-10346. Implement 
asynchronous
[Jun 6, 2016 8:31:23 AM] (szetszwo) Revert "Revert "HADOOP-13168. Support 
Future.get with timeout in ipc
[Jun 6, 2016 8:31:30 AM] (szetszwo) Revert "Revert "HDFS-10390. Implement 
asynchronous setAcl/getAclStatus
[Jun 6, 2016 8:31:34 AM] (szetszwo) Revert "Revert "HDFS-10431 Refactor and 
speedup TestAsyncDFSRename. 
[Jun 6, 2016 8:31:38 AM] (szetszwo) Revert "Revert "HDFS-10430. Reuse 
FileSystem#access in TestAsyncDFS.
[Jun 6, 2016 8:31:43 AM] (szetszwo) Revert "Revert "HADOOP-13226 Support async 
call retry and failover.""
[Jun 6, 2016 9:30:51 PM] (mingma) MAPREDUCE-5044. Have AM trigger jstack on 
task attempts that timeout
[Jun 6, 2016 9:42:36 PM] (stevel) HADOOP-12807 S3AFileSystem should read AWS 
credentials from environment
[Jun 6, 2016 10:52:39 PM] (zhz) HDFS-10458. getFileEncryptionInfo should return 
quickly for
[Jun 7, 2016 4:06:52 AM] (Arun Suresh) YARN-5185. StageAllocaterGreedyRLE: Fix 
NPE in corner case. (Carlo
[Jun 7, 2016 4:18:32 AM] (Arun Suresh) YARN-4525. Fix bug in 
RLESparseResourceAllocation.getRangeOverlapping().
[Jun 7, 2016 5:50:15 AM] (rohithsharmaks) YARN-5118. Tests fails with localizer 
port bind exception. Contributed




-1 overall


The following subsystems voted -1:
docker


Powered by Apache Yetus 0.4.0-SNAPSHOT   http://yetus.apache.org



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