[jira] [Created] (HADOOP-13247) The CACHE entry in FileSystem is not removed if exception happened in close

[zhihai xu (JIRA)]

zhihai xu created HADOOP-13247:
--

 Summary: The CACHE entry in FileSystem is not removed if exception 
happened in close
 Key: HADOOP-13247
 URL: https://issues.apache.org/jira/browse/HADOOP-13247
 Project: Hadoop Common
  Issue Type: Bug
  Components: fs
Affects Versions: 2.8.0
Reporter: zhihai xu
Assignee: zhihai xu


The CACHE entry in FileSystem is not removed if exception happened in close. It 
causes "Filesystem closed" IOException if the same filesystem is used later.
The following is stack trace for the exception coming out of close:
{code}
2016-06-07 18:21:18,201 ERROR hive.ql.exec.DDLTask: 
org.apache.hadoop.hive.ql.metadata.HiveException: 
java.lang.reflect.UndeclaredThrowableException
at org.apache.hadoop.hive.ql.metadata.Hive.createTable(Hive.java:756)
at org.apache.hadoop.hive.ql.exec.DDLTask.createTable(DDLTask.java:4022)
at org.apache.hadoop.hive.ql.exec.DDLTask.execute(DDLTask.java:306)
at org.apache.hadoop.hive.ql.exec.Task.executeTask(Task.java:172)
at 
org.apache.hadoop.hive.ql.exec.TaskRunner.runSequential(TaskRunner.java:88)
at org.apache.hadoop.hive.ql.Driver.launchTask(Driver.java:1679)
at org.apache.hadoop.hive.ql.Driver.execute(Driver.java:1422)
at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:1205)
at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1052)
at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1047)
at 
org.apache.hive.service.cli.operation.SQLOperation.runQuery(SQLOperation.java:158)
at 
org.apache.hive.service.cli.operation.SQLOperation.access$100(SQLOperation.java:76)
at 
org.apache.hive.service.cli.operation.SQLOperation$1$1.run(SQLOperation.java:219)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at 
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628)
at 
org.apache.hive.service.cli.operation.SQLOperation$1.run(SQLOperation.java:231)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy18.getFileInfo(Unknown Source)
at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1988)
at 
org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1118)
at 
org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:1114)
at 
org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
at 
org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1114)
at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1400)
at 
org.apache.hadoop.fs.FileSystem.processDeleteOnExit(FileSystem.java:1383)
at org.apache.hadoop.fs.FileSystem.close(FileSystem.java:2006)
at 
org.apache.hadoop.hdfs.DistributedFileSystem.close(DistributedFileSystem.java:900)
at 
org.apache.hadoop.hive.metastore.Warehouse.closeFs(Warehouse.java:122)
at org.apache.hadoop.hive.metastore.Warehouse.isDir(Warehouse.java:497)
at 
org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClient.createTempTable(SessionHiveMetaStoreClient.java:345)
at 
org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClient.create_table_with_environment_context(SessionHiveMetaStoreClient.java:93)
at 
org.apache.hadoop.hive.metastore.HiveMetaStoreClient.createTable(HiveMetaStoreClient.java:664)
at 
org.apache.hadoop.hive.metastore.HiveMetaStoreClient.createTable(HiveMetaStoreClient.java:652)
at sun.reflect.GeneratedMethodAccessor108.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.hadoop.hive.metastore.RetryingMetaStoreClient.invoke(RetryingMetaStoreClient.java:90)
at com.sun.proxy.$Proxy8.createTable(Unknown Source)
at sun.reflect.GeneratedMethodAccessor108.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.hadoop.hive.metastore.HiveMetaStoreClient$SynchronizedHandler.invoke(HiveMetaStoreClient.java:1909)
at com.sun.proxy.$Proxy8.createTable(Unknown Source)
at org.apache.hadoop.hive

Re: Pre-commit Docker image build failures on H2?

[Anu Engineer]

Hi Chris,
Thanks for bringing this up. I just ran into the same issue.

https://builds.apache.org/job/PreCommit-HDFS-Build/15700/console

But in my case it seems like a different host.  “Building remotely on H0”.

Thanks
Anu


On 6/6/16, 3:44 PM, "Chris Nauroth"  wrote:

>I'm curious if anyone has noticed issues with pre-commit failing during the 
>Docker image build on Jenkins node H2.  Here are a few examples.
>
>https://builds.apache.org/job/PreCommit-HADOOP-Build/9661/console
>
>https://builds.apache.org/job/PreCommit-HADOOP-Build/9662/console
>
>https://builds.apache.org/job/PreCommit-HADOOP-Build/9670/console
>
>These are all test runs for the same patch, but the patch just removes 5 lines 
>of Java code, so I don't expect the particular patch could cause a failure 
>like this.  I noticed that they all ran on H2.  It seems to be a problem 
>installing oracle-java8-installer:
>
>
>WARNING: The following packages cannot be authenticated!
>  oracle-java8-installer
>?[91mE: There are problems and -y was used without --force-yes
>?[0mThe command '/bin/sh -c apt-get -q install --no-install-recommends -y 
>oracle-java8-installer' returned a non-zero code: 100
>
>--Chris Nauroth


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

[jira] [Created] (HADOOP-13246) Support Mutable Short Gauge In Metrics2 lib

[Hanisha Koneru (JIRA)]

Hanisha Koneru created HADOOP-13246:
---

 Summary: Support Mutable Short Gauge In Metrics2 lib
 Key: HADOOP-13246
 URL: https://issues.apache.org/jira/browse/HADOOP-13246
 Project: Hadoop Common
  Issue Type: Improvement
  Components: metrics
Affects Versions: 3.0.0-alpha1
Reporter: Hanisha Koneru


Currently, MutableGaugeInt and MutableGaugeLong are the supported types of 
MutableGauge. Add MutableGaugeShort to this list for keeping track of metrics 
for which the int range is too big.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Zheng, Kai]

+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:cmcc...@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 pa

Re: Cannot create release artifacts for branch-2.8

[Wangda Tan]

It's also the best option to fix create-release. If we cannot get help to
fix the script, it seems the only choice is to maintain CHANGES.txt again
in branch-2.

On Tue, Jun 7, 2016 at 2:56 PM, Andrew Wang 
wrote:

> I'm not super happy about the alternative of reverting the auto-generated
> CHANGES/RL JIRAs, since it means we have to do CHANGES.txt maintenance
> again in branch-2. That's an overhead that we pay for every commit, and
> it's particularly bad when doing backports.
>
> As I commented on HADOOP-12892, I think the backport should be possible,
> and hopefully without backporting all the conflicting JIRAs. Maybe another
> bash-savvy contributor could attempt it?
>
>
>
> On Tue, Jun 7, 2016 at 2:45 PM, Wangda Tan  wrote:
>
>> >
>> > I'm not the one who cherry-picked them into branch-2, so I don't
>> > care either way.  I've been extremely open about targeting my code for
>> the
>> > past three years for trunk. With few exceptions, I generally only commit
>> > code I write or even review to branch-2 if someone practically begs me.
>> > That branch needs to die.  Given my current situation, I'm certainly not
>> > going to spend any unpaid time on it.
>>
>>
>> Yeah, we all knew your preferences about this, you have the choice to work
>> on whatever branch you like. :)
>>
>> Actually this question is to Andrew and Akira, I want to get consensus on
>> this.
>>
>> Thanks,
>> Wangda
>>
>
>

Re: Cannot create release artifacts for branch-2.8

[Andrew Wang]

I'm not super happy about the alternative of reverting the auto-generated
CHANGES/RL JIRAs, since it means we have to do CHANGES.txt maintenance
again in branch-2. That's an overhead that we pay for every commit, and
it's particularly bad when doing backports.

As I commented on HADOOP-12892, I think the backport should be possible,
and hopefully without backporting all the conflicting JIRAs. Maybe another
bash-savvy contributor could attempt it?



On Tue, Jun 7, 2016 at 2:45 PM, Wangda Tan  wrote:

> >
> > I'm not the one who cherry-picked them into branch-2, so I don't
> > care either way.  I've been extremely open about targeting my code for
> the
> > past three years for trunk. With few exceptions, I generally only commit
> > code I write or even review to branch-2 if someone practically begs me.
> > That branch needs to die.  Given my current situation, I'm certainly not
> > going to spend any unpaid time on it.
>
>
> Yeah, we all knew your preferences about this, you have the choice to work
> on whatever branch you like. :)
>
> Actually this question is to Andrew and Akira, I want to get consensus on
> this.
>
> Thanks,
> Wangda
>

Re: Cannot create release artifacts for branch-2.8

[Wangda Tan]

>
> I'm not the one who cherry-picked them into branch-2, so I don't
> care either way.  I've been extremely open about targeting my code for the
> past three years for trunk. With few exceptions, I generally only commit
> code I write or even review to branch-2 if someone practically begs me.
> That branch needs to die.  Given my current situation, I'm certainly not
> going to spend any unpaid time on it.


Yeah, we all knew your preferences about this, you have the choice to work
on whatever branch you like. :)

Actually this question is to Andrew and Akira, I want to get consensus on
this.

Thanks,
Wangda

Re: Cannot create release artifacts for branch-2.8

[Allen Wittenauer]

> On Jun 7, 2016, at 1:44 PM, Wangda Tan  wrote:
> 
> That gonna be very helpful, but I guess it only works on trunk, correct? At
> least many of the parameters you mentioned are not in create-release.sh of
> branch-2.

Yup.  create-release was rewritten in trunk.  The previous version had 
some interesting race conditions and other problems that made any releases 
built from it highly suspect.  (never mind the whole 'against ASF policy' 
problem when run on Jenkins)

> We may need to make a decision for this in branch-2. Honestly, I have
> little understanding about shell script related stuffs, if I cannot get
> help about fixing create-release.sh, I would prefer to revert both of
> HADOOP-12022/HADOOP-11792 from branch-2/branch-2.8 and adding CHANGES.txt
> manually.
> 
> Would like to hear your thoughts.

I'm not the one who cherry-picked them into branch-2, so I don't care 
either way.  I've been extremely open about targeting my code for the past 
three years for trunk. With few exceptions, I generally only commit code I 
write or even review to branch-2 if someone practically begs me.  That branch 
needs to die.  Given my current situation, I'm certainly not going to spend any 
unpaid time on it.
-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

Re: Cannot create release artifacts for branch-2.8

[Wangda Tan]

+ Andrew/Akira

On Tue, Jun 7, 2016 at 1:44 PM, Wangda Tan  wrote:

> That gonna be very helpful, but I guess it only works on trunk, correct?
> At least many of the parameters you mentioned are not in create-release.sh
> of branch-2.
>
> We may need to make a decision for this in branch-2. Honestly, I have
> little understanding about shell script related stuffs, if I cannot get
> help about fixing create-release.sh, I would prefer to revert both of
> HADOOP-12022/HADOOP-11792 from branch-2/branch-2.8 and adding CHANGES.txt
> manually.
>
> Would like to hear your thoughts.
>
> + Andrew/Akira who backported the two patches to branch-2, is it safe to
> revert the two patches? Are there any other dependency patches I need to
> take care?
>
> Thanks,
> Wangda
>
>
> On Tue, Jun 7, 2016 at 11:45 AM, Allen Wittenauer <
> allenwittena...@yahoo.com.invalid> wrote:
>
>>
>> > On Jun 7, 2016, at 11:37 AM, Wangda Tan  wrote:
>> >
>> > I have tested both, create-releases fails on my local box as well.
>> >
>> > According to the link you provided, we probably need to update how to
>> > release wiki
>> > .
>>
>>
>> I'm working on writing directions on how to use
>> dev-support/bin/create-release for an ASF release.  But short directions:
>>
>> * need a working .gpg directory
>> * use --asfrelease
>> * use --docker and --dockercache on Linux
>> * after vote passes, commit the generated release documentation
>> back to the various branches
>>
>>
>> -
>> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
>> For additional commands, e-mail: common-dev-h...@hadoop.apache.org
>>
>>
>

Re: Cannot create release artifacts for branch-2.8

[Wangda Tan]

That gonna be very helpful, but I guess it only works on trunk, correct? At
least many of the parameters you mentioned are not in create-release.sh of
branch-2.

We may need to make a decision for this in branch-2. Honestly, I have
little understanding about shell script related stuffs, if I cannot get
help about fixing create-release.sh, I would prefer to revert both of
HADOOP-12022/HADOOP-11792 from branch-2/branch-2.8 and adding CHANGES.txt
manually.

Would like to hear your thoughts.

+ Andrew/Akira who backported the two patches to branch-2, is it safe to
revert the two patches? Are there any other dependency patches I need to
take care?

Thanks,
Wangda


On Tue, Jun 7, 2016 at 11:45 AM, Allen Wittenauer <
allenwittena...@yahoo.com.invalid> wrote:

>
> > On Jun 7, 2016, at 11:37 AM, Wangda Tan  wrote:
> >
> > I have tested both, create-releases fails on my local box as well.
> >
> > According to the link you provided, we probably need to update how to
> > release wiki
> > .
>
>
> I'm working on writing directions on how to use
> dev-support/bin/create-release for an ASF release.  But short directions:
>
> * need a working .gpg directory
> * use --asfrelease
> * use --docker and --dockercache on Linux
> * after vote passes, commit the generated release documentation
> back to the various branches
>
>
> -
> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: common-dev-h...@hadoop.apache.org
>
>

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

[Colin McCabe]

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

[jira] [Created] (HADOOP-13245) Fix up some misc create-release issues

[Allen Wittenauer (JIRA)]

Allen Wittenauer created HADOOP-13245:
-

 Summary: Fix up some misc create-release issues
 Key: HADOOP-13245
 URL: https://issues.apache.org/jira/browse/HADOOP-13245
 Project: Hadoop Common
  Issue Type: Bug
  Components: build
Affects Versions: 3.0.0-alpha1
Reporter: Allen Wittenauer
Priority: Blocker


1. Apache Yetus 0.3.0 requires the dateutil.parser module for Python.
2. Missing -Pdocs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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-dev@hadoop.apache.org;
>> > hdfs-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org;
>> > yarn-...@hadoop.apache.org
>> > Subject: Re: Why there are so many revert operations on trunk?
>> >
>> > Folks,
>> >
>> > It is truly disappointing how we are escalating situations that can be
>> > resolved through basic communication.
>> >
>> > Things that shouldn’t have happened
>> > - After a few objections were raised, commits should have simply stopped
>> > before restarting again but only after consensus
>> > - Reverts (or revert and move to a feature-branch) shouldn’t have been
>> > unequivocally done without dropping a note / informing everyone /
>> building
>> > consensus. And no, not even a release-manager gets this free pass. Not
>> on
>> > branch-2, not on trunk, not anywhere.
>> > - Freaking out on -1’s and reverts - we as a community need to be less
>> > stigmatic about -1s / reverts.
>> >
>> > Trunk releases:
>> > This is the other important bit about huge difference of expectations
>> > between the two sides w.r.t trunk and branching. Till now, we’ve never
>> made
>> > releases out of trunk. So in-progress features that people deemed to not
>> > need a feature branch could go into trunk withou

Re: Cannot create release artifacts for branch-2.8

[Allen Wittenauer]

> On Jun 7, 2016, at 11:37 AM, Wangda Tan  wrote:
> 
> I have tested both, create-releases fails on my local box as well.
> 
> According to the link you provided, we probably need to update how to
> release wiki
> .


I'm working on writing directions on how to use dev-support/bin/create-release 
for an ASF release.  But short directions:

* need a working .gpg directory
* use --asfrelease 
* use --docker and --dockercache on Linux
* after vote passes, commit the generated release documentation back to 
the various branches


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

Re: Cannot create release artifacts for branch-2.8

[Wangda Tan]

I have tested both, create-releases fails on my local box as well.

According to the link you provided, we probably need to update how to
release wiki
.

On Tue, Jun 7, 2016 at 6:22 AM, Allen Wittenauer 
wrote:

>
> > On Jun 6, 2016, at 10:50 PM, Wangda Tan  wrote:
> >
> > Hi Hadoop Devs,
> >
> > As you know, we're pushing 2.8.0 releases recently, there're couple of
> > issues that block creating release artifacts from source code.
> >
> > I tried following approaches:
> > 1) Run build through Hadoop Jenkins Job:
>
>
> http://www.apache.org/dev/release.html#owned-controlled-hardware
>
>
>

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-dev@hadoop.apache.org;
> > hdfs-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org;
> > yarn-...@hadoop.apache.org
> > Subject: Re: Why there are so many revert operations on trunk?
> >
> > Folks,
> >
> > It is truly disappointing how we are escalating situations that can be
> > resolved through basic communication.
> >
> > Things that shouldn’t have happened
> > - After a few objections were raised, commits should have simply stopped
> > before restarting again but only after consensus
> > - Reverts (or revert and move to a feature-branch) shouldn’t have been
> > unequivocally done without dropping a note / informing everyone /
> building
> > consensus. And no, not even a release-manager gets this free pass. Not on
> > branch-2, not on trunk, not anywhere.
> > - Freaking out on -1’s and reverts - we as a community need to be less
> > stigmatic about -1s / reverts.
> >
> > Trunk releases:
> > This is the other important bit about huge difference of expectations
> > between the two sides w.r.t trunk and branching. Till now, we’ve never
> made
> > releases out of trunk. So in-progress features that people deemed to not
> > need a feature branch could go into trunk without much trouble. Given
> that
> > we are now making releases off trunk, I can see (a) the RM saying "no,
> > don’t put in-progress stuff and (b) the contributors saying “no we don’t
> > want the overhead of a branch”. I’ve raised related topics (but only
> > focusing on incompatible changes) before -
> > http://markmail.org/message/m6x73t6srlchywsn - but we never decided
> > anything.
> >
> > We need to at the least force a reset of expectations w.r.t

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-dev@hadoop.apache.org;
> hdfs-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org;
> yarn-...@hadoop.apache.org
> Subject: Re: Why there are so many revert operations on trunk?
>
> Folks,
>
> It is truly disappointing how we are escalating situations that can be
> resolved through basic communication.
>
> Things that shouldn’t have happened
> - After a few objections were raised, commits should have simply stopped
> before restarting again but only after consensus
> - Reverts (or revert and move to a feature-branch) shouldn’t have been
> unequivocally done without dropping a note / informing everyone / building
> consensus. And no, not even a release-manager gets this free pass. Not on
> branch-2, not on trunk, not anywhere.
> - Freaking out on -1’s and reverts - we as a community need to be less
> stigmatic about -1s / reverts.
>
> Trunk releases:
> This is the other important bit about huge difference of expectations
> between the two sides w.r.t trunk and branching. Till now, we’ve never made
> releases out of trunk. So in-progress features that people deemed to not
> need a feature branch could go into trunk without much trouble. Given that
> we are now making releases off trunk, I can see (a) the RM saying "no,
> don’t put in-progress stuff and (b) the contributors saying “no we don’t
> want the overhead of a branch”. I’ve raised related topics (but only
> focusing on incompatible changes) before -
> http://markmail.org/message/m6x73t6srlchywsn - but we never decided
> anything.
>
> We need to at the least force a reset of expectations w.r.t how trunk and
> small / medium / incompatible changes there are treated. We should hold off
> making a release off trunk before this gets fully discussed in the
> community and we all reach a consensus.
>
> * Without a user API, there's no way for people to use it, so not much
> advantage to having it in a release
>
> Since the code is separate and probably won't break any existing code, I
> won't -1 if you want to include this in a release without a user API, but
> again, I question the utility of including code that can't be used.
>
> Clearly, there are two sides to this argument. One side claims the absence
> of user-facing public / stable APIs, and that for all purposes this is
> dead-code for everyone other than the few early adopters who want to
> expe

Branch-2.6 Pre-Commit Jenkins broken?

[Zhe Zhang]

Has anyone gotten a successful run recently? Thanks.

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-dev@hadoop.apache.org; 
hdfs-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org; 
yarn-...@hadoop.apache.org
Subject: Re: Why there are so many revert operations on trunk?

Folks,

It is truly disappointing how we are escalating situations that can be resolved 
through basic communication.

Things that shouldn’t have happened
- After a few objections were raised, commits should have simply stopped before 
restarting again but only after consensus
- Reverts (or revert and move to a feature-branch) shouldn’t have been 
unequivocally done without dropping a note / informing everyone / building 
consensus. And no, not even a release-manager gets this free pass. Not on 
branch-2, not on trunk, not anywhere.
- Freaking out on -1’s and reverts - we as a community need to be less 
stigmatic about -1s / reverts.

Trunk releases:
This is the other important bit about huge difference of expectations between 
the two sides w.r.t trunk and branching. Till now, we’ve never made releases 
out of trunk. So in-progress features that people deemed to not need a feature 
branch could go into trunk without much trouble. Given that we are now making 
releases off trunk, I can see (a) the RM saying "no, don’t put in-progress 
stuff and (b) the contributors saying “no we don’t want the overhead of a 
branch”. I’ve raised related topics (but only focusing on incompatible changes) 
before - http://markmail.org/message/m6x73t6srlchywsn - but we never decided 
anything.

We need to at the least force a reset of expectations w.r.t how trunk and small 
/ medium / incompatible changes there are treated. We should hold off making a 
release off trunk before this gets fully discussed in the community and we all 
reach a consensus.

* Without a user API, there's no way for people to use it, so not much
advantage to having it in a release

Since the code is separate and probably won't break any existing code, I
won't -1 if you want to include this in a release without a user API, but
again, I question the utility of including code that can't be used.

Clearly, there are two sides to this argument. One side claims the absence of 
user-facing public / stable APIs, and that for all purposes this is dead-code 
for everyone other than the few early adopters who want to experiment with it. 
The other argument is to not put this code before a user API. Again, I’d 
discuss with fellow community members before making what the other side 
perceives as unacceptable moves.

>From 2.8.0 perspective, it shouldn’t have landed there in the first place - I 
>have been pushing for a release for a while with help only from a few members 
>of the community. But if you say that it has no material impact on the user 
>story, having a by-default switched-off feature that *doesn’t* destabilize the 
>core release, I’d be willing to let it pass.

+Vinod

Re: Cannot create release artifacts for branch-2.8

[Allen Wittenauer]

> On Jun 6, 2016, at 10:50 PM, Wangda Tan  wrote:
> 
> Hi Hadoop Devs,
> 
> As you know, we're pushing 2.8.0 releases recently, there're couple of
> issues that block creating release artifacts from source code.
> 
> I tried following approaches:
> 1) Run build through Hadoop Jenkins Job:


http://www.apache.org/dev/release.html#owned-controlled-hardware



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

[jira] [Resolved] (HADOOP-3584) Add an explicit HadoopConfigurationException that extends RuntimeException

[Steve Loughran (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HADOOP-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Loughran resolved HADOOP-3584.

   Resolution: Won't Fix
Fix Version/s: 2.8.0

Just noticed this JIRA hanging around. Clearly nobody else cares for it. 
Closing for now

> Add an explicit HadoopConfigurationException that extends RuntimeException
> --
>
> Key: HADOOP-3584
> URL: https://issues.apache.org/jira/browse/HADOOP-3584
> Project: Hadoop Common
>  Issue Type: Improvement
>  Components: conf
>Affects Versions: 0.19.0
>Reporter: Steve Loughran
>Priority: Minor
> Fix For: 2.8.0
>
>
> It is possible for a get() or set() operation to throw an exception today, 
> especially if a security manager is blocking property access. As more complex 
> cross-references are used, the likelihood for failure is higher.
> Yet there is no way for a Configuration or subclass to throw an exception 
> today except by throwing a general purpose RuntimeException.
> I propose having a specific HadoopConfigurationException that extends 
> RuntimeException. Classes that read in configurations can explicitly catch 
> and handle these. The exception could
> * be raised on some parse error (a float attribute is not a parseable float, 
> etc)
> * be raised on some error caused by an implementation of a configuration 
> service API
> * wrap underlying errors from different implementations (like JNDI exceptions)
> * wrap security errors and other generic problems
> I'm not going to propose having specific errors for parsing problems versus 
> undefined name,value pair though that may be useful feature creep. It 
> certainly makes bridging from different back-ends trickier. 
> This would not be incompatible with the existing code, at least from my 
> current experiments. What is more likely to cause problems is having the 
> get() operations failing, as that is not something that is broadly tested 
> (yet). If we do want to test it, we could have a custom mock back-end that 
> could be configured to fail on a get() of a specific option.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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 purposes this is dead-co