Build failed in Jenkins: Hadoop-Hdfs-trunk #1415

2013-05-30 Thread Apache Jenkins Server 
See 

Changes:

[sseth] YARN-719. Move RMIdentifier from Container to ContainerTokenIdentifier. 
Contributed by Vinod Kumar Vavilapalli.

[vinodkv] HADOOP-9574. Fix for timing issues in the original patch's test-case.

[vinodkv] YARN-638. Modified ResourceManager to restore RMDelegationTokens 
after restarting. Contributed by Jian He.

[vinodkv] YARN-714. Added NMTokens to be sent to AMs as part of heart-beat 
response. Contributed by Omkar Vinit Joshi.

[jing9] HDFS-4863. The root directory should be added to the snapshottable 
directory list while loading fsimage. Contributed by Jing Zhao

[vinodkv] MAPREDUCE-5263. Bring back old methods and fields in 
filecache.DistributedCache for binary compatibility with mapred in 1.x. 
Contributed by Zhijie Shen.

[vinodkv] HADOOP-9574. Added new methods in 
AbstractDelegationTokenSecretManager for helping YARN ResourceManager to reuse 
code for RM restart. Contributed by Jian He.

[vinodkv] YARN-578. Fixed NM to use SecureIOUtils for reading and aggregating 
logs. Contributed by Omkar Vinit Joshi.

[jing9] HDFS-4857. Snapshot.Root and AbstractINodeDiff#snapshotINode should not 
be put into INodeMap when loading FSImage. Contributed by Jing Zhao

[brandonli] HDFS-4846. Clean up snapshot CLI commands output stacktrace for 
invalid arguments. Contributed by Jing Zhao

[jing9] HDFS-4842. Identify the correct prior snapshot when deleting a snapshot 
under a renamed subtree. Contributed by Jing Zhao.

[tucu] HDFS-4865. Remove sub resource warning from httpfs log at startup time. 
(ywskycn via tucu)

[jlowe] YARN-512. Log aggregation root directory check is more expensive than 
it needs to be. Contributed by Maysam Yabandeh

--
[...truncated 14315 lines...]
Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating

Hadoop-Hdfs-trunk - Build # 1415 - Still Failing

2013-05-30 Thread Apache Jenkins Server 
See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1415/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 14508 lines...]
[INFO] 
[INFO] --- maven-source-plugin:2.1.2:test-jar-no-fork (hadoop-java-sources) @ 
hadoop-hdfs-project ---
[INFO] 
[INFO] --- maven-enforcer-plugin:1.0:enforce (dist-enforce) @ 
hadoop-hdfs-project ---
[INFO] 
[INFO] --- maven-site-plugin:3.0:attach-descriptor (attach-descriptor) @ 
hadoop-hdfs-project ---
[INFO] 
[INFO] --- maven-javadoc-plugin:2.8.1:jar (module-javadocs) @ 
hadoop-hdfs-project ---
[INFO] Not executing Javadoc as the project is not a Java classpath-capable 
package
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.6:checkstyle (default-cli) @ 
hadoop-hdfs-project ---
[INFO] 
[INFO] --- findbugs-maven-plugin:2.3.2:findbugs (default-cli) @ 
hadoop-hdfs-project ---
[INFO] ** FindBugsMojo execute ***
[INFO] canGenerate is false
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Hadoop HDFS  SUCCESS 
[1:36:48.729s]
[INFO] Apache Hadoop HttpFS .. SUCCESS [2:27.662s]
[INFO] Apache Hadoop HDFS BookKeeper Journal . FAILURE [54.833s]
[INFO] Apache Hadoop HDFS Project  SUCCESS [0.037s]
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 1:40:12.028s
[INFO] Finished at: Thu May 30 13:13:29 UTC 2013
[INFO] Final Memory: 56M/711M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test (default-test) on 
project hadoop-hdfs-bkjournal: There are test failures.
[ERROR] 
[ERROR] Please refer to 
/home/jenkins/jenkins-slave/workspace/Hadoop-Hdfs-trunk/trunk/hadoop-hdfs-project/hadoop-hdfs/src/contrib/bkjournal/target/surefire-reports
 for the individual test results.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :hadoop-hdfs-bkjournal
Build step 'Execute shell' marked build as failure
Archiving artifacts
Updating MAPREDUCE-5263
Updating HDFS-4846
Updating YARN-578
Updating HDFS-4857
Updating HADOOP-9574
Updating HDFS-4842
Updating YARN-719
Updating YARN-512
Updating HDFS-4865
Updating HDFS-4863
Updating YARN-714
Updating YARN-638
Sending e-mails to: hdfs-dev@hadoop.apache.org
Email was triggered for: Failure
Sending email for trigger: Failure



###
## FAILED TESTS (if any) 
##
No tests ran.

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Arun C Murthy 
I see you just re-opened MAPREUDCE-4211.

Why not include MAPREDUCE-4211 as well rather than create one release per patch?

Also, this is the first time we are seeing a four-numbered scheme in Hadoop. 
Why not call this 2.0.5-alpha?

Arun

On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:

> All,
> 
> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I would
> like to release.
> 
> This is a stabilization release that includes fixed for a couple a of issues
> discovered in the testing with BigTop 0.6.0 release candidate.
> 
> The RC is available at: 
> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
> The RC tag in svn is here: 
> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
> 
> The maven artifacts are available via repository.apache.org.
> 
> Please try the release bits and vote; the vote will run for the usual 7 days.
> 
> Thanks for your voting
>  Cos
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Arun C Murthy 
Sorry, it should be MAPREDUCE-5211 (not MAPREDUCE-4211).

thanks,
Arun

On May 30, 2013, at 10:57 AM, Arun C Murthy wrote:

> I see you just re-opened MAPREUDCE-4211.
> 
> Why not include MAPREDUCE-4211 as well rather than create one release per 
> patch?
> 
> Also, this is the first time we are seeing a four-numbered scheme in Hadoop. 
> Why not call this 2.0.5-alpha?
> 
> Arun
> 
> On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
> 
>> All,
>> 
>> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I 
>> would
>> like to release.
>> 
>> This is a stabilization release that includes fixed for a couple a of issues
>> discovered in the testing with BigTop 0.6.0 release candidate.
>> 
>> The RC is available at: 
>> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
>> The RC tag in svn is here: 
>> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
>> 
>> The maven artifacts are available via repository.apache.org.
>> 
>> Please try the release bits and vote; the vote will run for the usual 7 days.
>> 
>> Thanks for your voting
>>  Cos
>> 
> 
> 

--
Arun C. Murthy
Hortonworks Inc.
http://hortonworks.com/

[jira] [Created] (HDFS-4867) metaSave NPEs when there are invalid blocks in repl queue.

2013-05-30 Thread Kihwal Lee (JIRA) 
Kihwal Lee created HDFS-4867:


 Summary: metaSave NPEs when there are invalid blocks in repl queue.
 Key: HDFS-4867
 URL: https://issues.apache.org/jira/browse/HDFS-4867
 Project: Hadoop HDFS
  Issue Type: Bug
  Components: namenode
Affects Versions: 2.0.4-alpha, 0.23.7
Reporter: Kihwal Lee


Since metaSave cannot get the inode holding a orphaned/invalid block, it NPEs 
and stops generating further report. Normally ReplicationMonitor removes them 
quickly, but if the queue is huge, it takes very long time. Also in safe mode, 
they stay.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Konstantin Boudnik 
On Thu, May 30, 2013 at 10:57AM, Arun C Murthy wrote:
> I see you just re-opened MAPREUDCE-5211.
> 
> Why not include MAPREDUCE-5211 as well rather than create one release per 
> patch?

Arun, it is unclear if MAPREDUCE-5211 has implications in 2.0.4 as per 
https://issues.apache.org/jira/browse/MAPREDUCE-5211?focusedCommentId=13670574&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13670574

Hence, there's a good chance that it never will be backported. And I don't
have any plans to created 'a release per patch'.

> Also, this is the first time we are seeing a four-numbered scheme in Hadoop.
> Why not call this 2.0.5-alpha?

There were precedents in four-numbered schemes before: 0.20.20[3-5].0 comes to
mind.

As for 2.0.5-alpha: The release numbering games and votes that had happened in
the last few weeks are very confusing. Some of them never been concluded, the
branches are moved and artifact versions seem to be colliding. 2.0.4.x seems
to work well for the stabilization purposes and it will allow to unblock
downstream and integration projects quickly.

Cos

> Arun
> 
> On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
> 
> > All,
> > 
> > I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I 
> > would
> > like to release.
> > 
> > This is a stabilization release that includes fixed for a couple a of issues
> > discovered in the testing with BigTop 0.6.0 release candidate.
> > 
> > The RC is available at: 
> > http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
> > The RC tag in svn is here: 
> > http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
> > 
> > The maven artifacts are available via repository.apache.org.
> > 
> > Please try the release bits and vote; the vote will run for the usual 7 
> > days.
> > 
> > Thanks for your voting
> >  Cos
> > 
> 
>

[jira] [Created] (HDFS-4868) Clean up error message when trying to snapshot using ViewFileSystem

2013-05-30 Thread Stephen Chu (JIRA) 
Stephen Chu created HDFS-4868:
-

 Summary: Clean up error message when trying to snapshot using 
ViewFileSystem
 Key: HDFS-4868
 URL: https://issues.apache.org/jira/browse/HDFS-4868
 Project: Hadoop HDFS
  Issue Type: Improvement
  Components: snapshots
Reporter: Stephen Chu
Priority: Minor


Snapshots aren't supported for the ViewFileSystem. When users try to create a 
snapshot, they'll run into a message like the following:

{code}
schu-mbp:presentation schu$ hadoop fs -createSnapshot /user/schu
-createSnapshot: Fatal internal error
java.lang.UnsupportedOperationException: ViewFileSystem doesn't support 
createSnapshot
at org.apache.hadoop.fs.FileSystem.createSnapshot(FileSystem.java:2285)
at 
org.apache.hadoop.fs.shell.SnapshotCommands$CreateSnapshot.processArguments(SnapshotCommands.java:87)
at 
org.apache.hadoop.fs.shell.Command.processRawArguments(Command.java:194)
at org.apache.hadoop.fs.shell.Command.run(Command.java:155)
at org.apache.hadoop.fs.FsShell.run(FsShell.java:255)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84)
at org.apache.hadoop.fs.FsShell.main(FsShell.java:305)
{code}

To make things more readable and avoid confusion, it would be helpful to clean 
up the error message stacktrace and just state that ViewFileSystem doesn't 
support createSnapshot, similar to what was done in HDFS-4846. The "fatal 
internal error" message is a bit scary and it might be useful to remove that 
message to avoid confusion from operators.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Konstantin Shvachko 
+1
I verified checksums, the signature, built sources on CentOS, ran tests and
a few hadoop commands.

Thanks,
--Konst


On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik  wrote:

> All,
>
> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I
> would
> like to release.
>
> This is a stabilization release that includes fixed for a couple a of
> issues
> discovered in the testing with BigTop 0.6.0 release candidate.
>
> The RC is available at:
> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
> The RC tag in svn is here:
> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
>
> The maven artifacts are available via repository.apache.org.
>
> Please try the release bits and vote; the vote will run for the usual 7
> days.
>
> Thanks for your voting
>   Cos
>
>

Re: [VOTE] Release Apache Hadoop 0.23.8

2013-05-30 Thread Robert Evans 
+1

Downloaded the release and ran a few basic tests.

--Bobby

On 5/28/13 11:00 AM, "Thomas Graves"  wrote:

>
>I've created a release candidate (RC0) for hadoop-0.23.8 that I would like
>to release.
>
>This release is a sustaining release with several important bug fixes in
>it.  The most critical one is MAPREDUCE-5211.
>
>The RC is available at:
>http://people.apache.org/~tgraves/hadoop-0.23.8-candidate-0/
>The RC tag in svn is here:
>http://svn.apache.org/viewvc/hadoop/common/tags/release-0.23.8-rc0/
>
>The maven artifacts are available via repository.apache.org.
>
>Please try the release and vote; the vote will run for the usual 7 days.
>
>I am +1 (binding).
>
>thanks,
>Tom Graves
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Konstantin Shvachko 
> Why not call this 2.0.5-alpha?

Technically, current branch-2 uses 2.0.5-SNAPSHOT and produces maven
artifacts with that version.
So having another version with the same numbers will be confusing.
Therefore 4-level numbers.
I thought I mentioned it to you before.

Thanks,
--Konst


On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy  wrote:

> I see you just re-opened MAPREUDCE-4211.
>
> Why not include MAPREDUCE-4211 as well rather than create one release per
> patch?
>
> Also, this is the first time we are seeing a four-numbered scheme in
> Hadoop. Why not call this 2.0.5-alpha?
>
> Arun
>
> On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
>
> > All,
> >
> > I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I
> would
> > like to release.
> >
> > This is a stabilization release that includes fixed for a couple a of
> issues
> > discovered in the testing with BigTop 0.6.0 release candidate.
> >
> > The RC is available at:
> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
> > The RC tag in svn is here:
> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
> >
> > The maven artifacts are available via repository.apache.org.
> >
> > Please try the release bits and vote; the vote will run for the usual 7
> days.
> >
> > Thanks for your voting
> >  Cos
> >
>
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Chris Douglas 
On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy  wrote:
> Why not include MAPREDUCE-4211 as well rather than create one release per 
> patch?

>From Cos's description, it sounded like these were backports of fixes
to help Sqoop2 and fix some build issues. If it's not just to fixup
leftover bugs in 2.0.4 *once* so downstream projects can integrate
against 2.0.4.1, and this a release series, then I've completely
misunderstood the purpose.

Cos, are you planning 2.0.4.2?

> Also, this is the first time we are seeing a four-numbered scheme in Hadoop. 
> Why not call this 2.0.5-alpha?

Good point. Since it contains only backports from branch-2, it would
make sense for it to be an intermediate release.

I shouldn't have to say this, but I'm changing my vote to -1 while we
work this out. -C

> On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
>
>> All,
>>
>> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I 
>> would
>> like to release.
>>
>> This is a stabilization release that includes fixed for a couple a of issues
>> discovered in the testing with BigTop 0.6.0 release candidate.
>>
>> The RC is available at: 
>> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
>> The RC tag in svn is here: 
>> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
>>
>> The maven artifacts are available via repository.apache.org.
>>
>> Please try the release bits and vote; the vote will run for the usual 7 days.
>>
>> Thanks for your voting
>>  Cos
>>
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Alejandro Abdelnur 
On the version number we use, if it is greater than 2.0.4, I really don't
care. Though I think Konstantin argument that branch-2 is publishing as
2.0.5-SNAPSHOT has some ground (still, it could be argued that they are DEV
JARs so they can be  in flux).

On the changes that went into this RC, they are exactly a fix for Sqoop2 to
work with the release and a build fix for Bigtop. As far as I can tell
there is nothing else in this RC as compared with 2.0.4-alpha.

So, effectively, this RC is just a fixup of 2.0.4 for Sqoop and Bigtop.

MAPREDUCE-5211 seems nasty enough to be included.

But I'd leave that to the RM (Cos in this case) to decide if  he wants to
go ahead without  it and then do a 2.0.4.2. Personally i would cut a second
RC including MAPREDUCE-5211. But I don't think that not having it would be
reason enough for a -1 (if that is the reason for the -1).

Thanks.




On Thu, May 30, 2013 at 1:48 PM, Chris Douglas  wrote:

> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy 
> wrote:
> > Why not include MAPREDUCE-4211 as well rather than create one release
> per patch?
>
> From Cos's description, it sounded like these were backports of fixes
> to help Sqoop2 and fix some build issues. If it's not just to fixup
> leftover bugs in 2.0.4 *once* so downstream projects can integrate
> against 2.0.4.1, and this a release series, then I've completely
> misunderstood the purpose.
>
> Cos, are you planning 2.0.4.2?
>
> > Also, this is the first time we are seeing a four-numbered scheme in
> Hadoop. Why not call this 2.0.5-alpha?
>
> Good point. Since it contains only backports from branch-2, it would
> make sense for it to be an intermediate release.
>
> I shouldn't have to say this, but I'm changing my vote to -1 while we
> work this out. -C
>
> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
> >
> >> All,
> >>
> >> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that
> I would
> >> like to release.
> >>
> >> This is a stabilization release that includes fixed for a couple a of
> issues
> >> discovered in the testing with BigTop 0.6.0 release candidate.
> >>
> >> The RC is available at:
> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
> >> The RC tag in svn is here:
> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
> >>
> >> The maven artifacts are available via repository.apache.org.
> >>
> >> Please try the release bits and vote; the vote will run for the usual 7
> days.
> >>
> >> Thanks for your voting
> >>  Cos
> >>
> >
> >
>



-- 
Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Konstantin Boudnik 
There's no misunderstanding Chris - this release is to unblock downstream.

As for your question: I don't have a crystal ball; I wish though. I think the
answer depends on will be there more blocking bugs found in the later releases
of Bigtop or other downstream components.
This is bugfix release and, I guess, if there are more bugs found in the
future - more releases would have to be cut. Isn't this is why the software is
being released?

Now, the -1: I am not clear about the justification. What exactly we expect to
"work out"?

Cos

On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy  wrote:
> > Why not include MAPREDUCE-4211 as well rather than create one release per 
> > patch?
> 
> From Cos's description, it sounded like these were backports of fixes
> to help Sqoop2 and fix some build issues. If it's not just to fixup
> leftover bugs in 2.0.4 *once* so downstream projects can integrate
> against 2.0.4.1, and this a release series, then I've completely
> misunderstood the purpose.
> 
> Cos, are you planning 2.0.4.2?
> 
> > Also, this is the first time we are seeing a four-numbered scheme in 
> > Hadoop. Why not call this 2.0.5-alpha?
> 
> Good point. Since it contains only backports from branch-2, it would
> make sense for it to be an intermediate release.
> 
> I shouldn't have to say this, but I'm changing my vote to -1 while we
> work this out. -C
> 
> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
> >
> >> All,
> >>
> >> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I 
> >> would
> >> like to release.
> >>
> >> This is a stabilization release that includes fixed for a couple a of 
> >> issues
> >> discovered in the testing with BigTop 0.6.0 release candidate.
> >>
> >> The RC is available at: 
> >> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
> >> The RC tag in svn is here: 
> >> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
> >>
> >> The maven artifacts are available via repository.apache.org.
> >>
> >> Please try the release bits and vote; the vote will run for the usual 7 
> >> days.
> >>
> >> Thanks for your voting
> >>  Cos
> >>
> >
> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Matt Foley 
Hi Cos,
I would also request that you renumber the release candidate to just
three-numbers, hence "2.0.5-alpha".

Arun, are you willing to start the 2.1.x name-space for your next release,
so that 2.0.x-alpha can become an intermediate stabilization branch as Cos
and Konst want?

I just think that using four-number schemes was symptomatic of the
near-forking we had back in the 0.20.xxx.y days, and I really don't want to
go back there.  Especially since you could say that "0.20.xxx.y" is just
three significant numbers, the leading zero being inconsequential.

So, would you please consider using 2.0.5-alpha?

As for the "2.0.5-SNAPSHOT" in the branch-2 versioning, that's standard
usage.  Whoever makes the 2.0.5 release (or any "next" release) is expected
to update the parent branch's SNAPSHOT default versioning, per
HowToReleasePostMavenization#Branching,
step 6.

Thanks,
--Matt


On Thu, May 30, 2013 at 11:52 AM, Konstantin Boudnik  wrote:

> On Thu, May 30, 2013 at 10:57AM, Arun C Murthy wrote:
> > I see you just re-opened MAPREUDCE-5211.
> >
> > Why not include MAPREDUCE-5211 as well rather than create one release
> per patch?
>
> Arun, it is unclear if MAPREDUCE-5211 has implications in 2.0.4 as per
>
> https://issues.apache.org/jira/browse/MAPREDUCE-5211?focusedCommentId=13670574&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13670574
>
> Hence, there's a good chance that it never will be backported. And I don't
> have any plans to created 'a release per patch'.
>
> > Also, this is the first time we are seeing a four-numbered scheme in
> Hadoop.
> > Why not call this 2.0.5-alpha?
>
> There were precedents in four-numbered schemes before: 0.20.20[3-5].0
> comes to
> mind.
>
> As for 2.0.5-alpha: The release numbering games and votes that had
> happened in
> the last few weeks are very confusing. Some of them never been concluded,
> the
> branches are moved and artifact versions seem to be colliding. 2.0.4.x
> seems
> to work well for the stabilization purposes and it will allow to unblock
> downstream and integration projects quickly.
>
> Cos
>
> > Arun
> >
> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
> >
> > > All,
> > >
> > > I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that
> I would
> > > like to release.
> > >
> > > This is a stabilization release that includes fixed for a couple a of
> issues
> > > discovered in the testing with BigTop 0.6.0 release candidate.
> > >
> > > The RC is available at:
> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
> > > The RC tag in svn is here:
> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
> > >
> > > The maven artifacts are available via repository.apache.org.
> > >
> > > Please try the release bits and vote; the vote will run for the usual
> 7 days.
> > >
> > > Thanks for your voting
> > >  Cos
> > >
> >
> >
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Chris Douglas 
On Thu, May 30, 2013 at 2:39 PM, Konstantin Boudnik  wrote:
> There's no misunderstanding Chris - this release is to unblock downstream.
>
> As for your question: I don't have a crystal ball; I wish though. I think the
> answer depends on will be there more blocking bugs found in the later releases
> of Bigtop or other downstream components.
> This is bugfix release and, I guess, if there are more bugs found in the
> future - more releases would have to be cut. Isn't this is why the software is
> being released?

Sure, but they're all backports from the release currently marked for
2.0.5. Either (a) these are really blocker bugs and we should roll a
patch release or (b) some bleeding-edge work needs to work around this
while branch-2 is released in the next few weeks. If it's not severe
enough to justify disrupting the versioning of snapshot maven
artifacts in branch-2, then we're clearly not in case (a).

I thought this was the result of extensive testing, and 2.0.4.1 was a
release to enable additional integration before 2.0.5. If we plan to
roll more releases as a subset of the bug fixes committed to branch-2
then just call it 2.0.5. Please make sure it- and any future,
intermediate release- is worth the disruption.

> Now, the -1: I am not clear about the justification. What exactly we expect to
> "work out"?

It's become fashionable to close threads and count votes in the middle
of the discussion. I changed my vote instead of trusting you. -C

> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy  wrote:
>> > Why not include MAPREDUCE-4211 as well rather than create one release per 
>> > patch?
>>
>> From Cos's description, it sounded like these were backports of fixes
>> to help Sqoop2 and fix some build issues. If it's not just to fixup
>> leftover bugs in 2.0.4 *once* so downstream projects can integrate
>> against 2.0.4.1, and this a release series, then I've completely
>> misunderstood the purpose.
>>
>> Cos, are you planning 2.0.4.2?
>>
>> > Also, this is the first time we are seeing a four-numbered scheme in 
>> > Hadoop. Why not call this 2.0.5-alpha?
>>
>> Good point. Since it contains only backports from branch-2, it would
>> make sense for it to be an intermediate release.
>>
>> I shouldn't have to say this, but I'm changing my vote to -1 while we
>> work this out. -C
>>
>> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
>> >
>> >> All,
>> >>
>> >> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I 
>> >> would
>> >> like to release.
>> >>
>> >> This is a stabilization release that includes fixed for a couple a of 
>> >> issues
>> >> discovered in the testing with BigTop 0.6.0 release candidate.
>> >>
>> >> The RC is available at: 
>> >> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
>> >> The RC tag in svn is here: 
>> >> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
>> >>
>> >> The maven artifacts are available via repository.apache.org.
>> >>
>> >> Please try the release bits and vote; the vote will run for the usual 7 
>> >> days.
>> >>
>> >> Thanks for your voting
>> >>  Cos
>> >>
>> >
>> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Konstantin Boudnik 
On Thu, May 30, 2013 at 03:18PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 2:39 PM, Konstantin Boudnik  wrote:
> > There's no misunderstanding Chris - this release is to unblock downstream.
> >
> > As for your question: I don't have a crystal ball; I wish though. I think 
> > the
> > answer depends on will be there more blocking bugs found in the later 
> > releases
> > of Bigtop or other downstream components.
> > This is bugfix release and, I guess, if there are more bugs found in the
> > future - more releases would have to be cut. Isn't this is why the software 
> > is
> > being released?
> 
> Sure, but they're all backports from the release currently marked for
> 2.0.5. Either (a) these are really blocker bugs and we should roll a
> patch release or (b) some bleeding-edge work needs to work around this
> while branch-2 is released in the next few weeks. If it's not severe
> enough to justify disrupting the versioning of snapshot maven
> artifacts in branch-2, then we're clearly not in case (a).
> 
> I thought this was the result of extensive testing, and 2.0.4.1 was a
> release to enable additional integration before 2.0.5. If we plan to
> roll more releases as a subset of the bug fixes committed to branch-2
> then just call it 2.0.5. Please make sure it- and any future,
> intermediate release- is worth the disruption.

There's no plans to release anything else at this point - this is a bug-fix
release, as I pointed out on a numerous occasions. There's no new features -
just 2 fixes.

2.0.5 matter became and still is too controversial at some point. The vote
started by Arun to override the results of the Konstantin's vote never been
closed. The downstream projects are handing in the middle of the air because
of that confusion. 

> > Now, the -1: I am not clear about the justification. What exactly we expect 
> > to
> > "work out"?
> 
> It's become fashionable to close threads and count votes in the middle
> of the discussion. I changed my vote instead of trusting you. -C

Have I missed something or you just called me a cheater and a lair right to my 
face?

Cos

> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy  
> >> wrote:
> >> > Why not include MAPREDUCE-4211 as well rather than create one release 
> >> > per patch?
> >>
> >> From Cos's description, it sounded like these were backports of fixes
> >> to help Sqoop2 and fix some build issues. If it's not just to fixup
> >> leftover bugs in 2.0.4 *once* so downstream projects can integrate
> >> against 2.0.4.1, and this a release series, then I've completely
> >> misunderstood the purpose.
> >>
> >> Cos, are you planning 2.0.4.2?
> >>
> >> > Also, this is the first time we are seeing a four-numbered scheme in 
> >> > Hadoop. Why not call this 2.0.5-alpha?
> >>
> >> Good point. Since it contains only backports from branch-2, it would
> >> make sense for it to be an intermediate release.
> >>
> >> I shouldn't have to say this, but I'm changing my vote to -1 while we
> >> work this out. -C
> >>
> >> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
> >> >
> >> >> All,
> >> >>
> >> >> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that 
> >> >> I would
> >> >> like to release.
> >> >>
> >> >> This is a stabilization release that includes fixed for a couple a of 
> >> >> issues
> >> >> discovered in the testing with BigTop 0.6.0 release candidate.
> >> >>
> >> >> The RC is available at: 
> >> >> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
> >> >> The RC tag in svn is here: 
> >> >> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
> >> >>
> >> >> The maven artifacts are available via repository.apache.org.
> >> >>
> >> >> Please try the release bits and vote; the vote will run for the usual 7 
> >> >> days.
> >> >>
> >> >> Thanks for your voting
> >> >>  Cos
> >> >>
> >> >
> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Konstantin Boudnik 
On Thu, May 30, 2013 at 03:11PM, Matt Foley wrote:
> Hi Cos,
> I would also request that you renumber the release candidate to just
> three-numbers, hence "2.0.5-alpha".
> 
> Arun, are you willing to start the 2.1.x name-space for your next release,
> so that 2.0.x-alpha can become an intermediate stabilization branch as Cos
> and Konst want?

Let's get the facts straight, Matt, please: this "want" has been expressed in
the official vote here http://s.apache.org/ZMf Apparently, 2.0.5-alpha is
blocked now because of the another vote that hasn't been closed yet for
whatever reason. In order to unblock a number of releases in downstream
component I have moved forward with this release. Do you have any material
objections to the release that pursue this goal?

> I just think that using four-number schemes was symptomatic of the
> near-forking we had back in the 0.20.xxx.y days, and I really don't want to
> go back there.  Especially since you could say that "0.20.xxx.y" is just
> three significant numbers, the leading zero being inconsequential.

I dare to remind that forth part of the version is reserved - not in a
parallel universe, of course - for "patch level" aka bug fixes. It hardly can
be taken a sign of 'forking' by any definition.

Cos

> So, would you please consider using 2.0.5-alpha?
> 
> As for the "2.0.5-SNAPSHOT" in the branch-2 versioning, that's standard
> usage.  Whoever makes the 2.0.5 release (or any "next" release) is expected
> to update the parent branch's SNAPSHOT default versioning, per
> HowToReleasePostMavenization#Branching,
> step 6.
> 
> Thanks,
> --Matt
> 
> 
> On Thu, May 30, 2013 at 11:52 AM, Konstantin Boudnik  wrote:
> 
> > On Thu, May 30, 2013 at 10:57AM, Arun C Murthy wrote:
> > > I see you just re-opened MAPREUDCE-5211.
> > >
> > > Why not include MAPREDUCE-5211 as well rather than create one release
> > per patch?
> >
> > Arun, it is unclear if MAPREDUCE-5211 has implications in 2.0.4 as per
> >
> > https://issues.apache.org/jira/browse/MAPREDUCE-5211?focusedCommentId=13670574&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13670574
> >
> > Hence, there's a good chance that it never will be backported. And I don't
> > have any plans to created 'a release per patch'.
> >
> > > Also, this is the first time we are seeing a four-numbered scheme in
> > Hadoop.
> > > Why not call this 2.0.5-alpha?
> >
> > There were precedents in four-numbered schemes before: 0.20.20[3-5].0
> > comes to
> > mind.
> >
> > As for 2.0.5-alpha: The release numbering games and votes that had
> > happened in
> > the last few weeks are very confusing. Some of them never been concluded,
> > the
> > branches are moved and artifact versions seem to be colliding. 2.0.4.x
> > seems
> > to work well for the stabilization purposes and it will allow to unblock
> > downstream and integration projects quickly.
> >
> > Cos
> >
> > > Arun
> > >
> > > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
> > >
> > > > All,
> > > >
> > > > I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that
> > I would
> > > > like to release.
> > > >
> > > > This is a stabilization release that includes fixed for a couple a of
> > issues
> > > > discovered in the testing with BigTop 0.6.0 release candidate.
> > > >
> > > > The RC is available at:
> > http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
> > > > The RC tag in svn is here:
> > http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
> > > >
> > > > The maven artifacts are available via repository.apache.org.
> > > >
> > > > Please try the release bits and vote; the vote will run for the usual
> > 7 days.
> > > >
> > > > Thanks for your voting
> > > >  Cos
> > > >
> > >
> > >
> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Jean-Daniel Cryans 
FWIW, not that I have a dog in this fight, but the only release with a
4th number (not including .0 like the 0.20.20x releases did) we had
was:

http://hadoop.6.n7.nabble.com/VOTE-Release-0-17-2-1-rc-0-td13398.html

0.17.2 was missing some native libs so 0.17.2.1 was released to fix
that critical issue instead of calling it .3

J-D

On Thu, May 30, 2013 at 3:52 PM, Konstantin Boudnik  wrote:
> On Thu, May 30, 2013 at 03:11PM, Matt Foley wrote:
>> Hi Cos,
>> I would also request that you renumber the release candidate to just
>> three-numbers, hence "2.0.5-alpha".
>>
>> Arun, are you willing to start the 2.1.x name-space for your next release,
>> so that 2.0.x-alpha can become an intermediate stabilization branch as Cos
>> and Konst want?
>
> Let's get the facts straight, Matt, please: this "want" has been expressed in
> the official vote here http://s.apache.org/ZMf Apparently, 2.0.5-alpha is
> blocked now because of the another vote that hasn't been closed yet for
> whatever reason. In order to unblock a number of releases in downstream
> component I have moved forward with this release. Do you have any material
> objections to the release that pursue this goal?
>
>> I just think that using four-number schemes was symptomatic of the
>> near-forking we had back in the 0.20.xxx.y days, and I really don't want to
>> go back there.  Especially since you could say that "0.20.xxx.y" is just
>> three significant numbers, the leading zero being inconsequential.
>
> I dare to remind that forth part of the version is reserved - not in a
> parallel universe, of course - for "patch level" aka bug fixes. It hardly can
> be taken a sign of 'forking' by any definition.
>
> Cos
>
>> So, would you please consider using 2.0.5-alpha?
>>
>> As for the "2.0.5-SNAPSHOT" in the branch-2 versioning, that's standard
>> usage.  Whoever makes the 2.0.5 release (or any "next" release) is expected
>> to update the parent branch's SNAPSHOT default versioning, per
>> HowToReleasePostMavenization#Branching,
>> step 6.
>>
>> Thanks,
>> --Matt
>>
>>
>> On Thu, May 30, 2013 at 11:52 AM, Konstantin Boudnik  wrote:
>>
>> > On Thu, May 30, 2013 at 10:57AM, Arun C Murthy wrote:
>> > > I see you just re-opened MAPREUDCE-5211.
>> > >
>> > > Why not include MAPREDUCE-5211 as well rather than create one release
>> > per patch?
>> >
>> > Arun, it is unclear if MAPREDUCE-5211 has implications in 2.0.4 as per
>> >
>> > https://issues.apache.org/jira/browse/MAPREDUCE-5211?focusedCommentId=13670574&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13670574
>> >
>> > Hence, there's a good chance that it never will be backported. And I don't
>> > have any plans to created 'a release per patch'.
>> >
>> > > Also, this is the first time we are seeing a four-numbered scheme in
>> > Hadoop.
>> > > Why not call this 2.0.5-alpha?
>> >
>> > There were precedents in four-numbered schemes before: 0.20.20[3-5].0
>> > comes to
>> > mind.
>> >
>> > As for 2.0.5-alpha: The release numbering games and votes that had
>> > happened in
>> > the last few weeks are very confusing. Some of them never been concluded,
>> > the
>> > branches are moved and artifact versions seem to be colliding. 2.0.4.x
>> > seems
>> > to work well for the stabilization purposes and it will allow to unblock
>> > downstream and integration projects quickly.
>> >
>> > Cos
>> >
>> > > Arun
>> > >
>> > > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
>> > >
>> > > > All,
>> > > >
>> > > > I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that
>> > I would
>> > > > like to release.
>> > > >
>> > > > This is a stabilization release that includes fixed for a couple a of
>> > issues
>> > > > discovered in the testing with BigTop 0.6.0 release candidate.
>> > > >
>> > > > The RC is available at:
>> > http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
>> > > > The RC tag in svn is here:
>> > http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
>> > > >
>> > > > The maven artifacts are available via repository.apache.org.
>> > > >
>> > > > Please try the release bits and vote; the vote will run for the usual
>> > 7 days.
>> > > >
>> > > > Thanks for your voting
>> > > >  Cos
>> > > >
>> > >
>> > >
>> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Konstantin Boudnik 
On Thu, May 30, 2013 at 04:08PM, Jean-Daniel Cryans wrote:
> FWIW, not that I have a dog in this fight, but the only release with a
> 4th number (not including .0 like the 0.20.20x releases did) we had
> was:
> 
> http://hadoop.6.n7.nabble.com/VOTE-Release-0-17-2-1-rc-0-td13398.html
> 
> 0.17.2 was missing some native libs so 0.17.2.1 was released to fix
> that critical issue instead of calling it .3

Exactly the point - the _bigfix_ release. Thanks for pointing out the
similarities.

Cos

> 
> J-D
> 
> On Thu, May 30, 2013 at 3:52 PM, Konstantin Boudnik  wrote:
> > On Thu, May 30, 2013 at 03:11PM, Matt Foley wrote:
> >> Hi Cos,
> >> I would also request that you renumber the release candidate to just
> >> three-numbers, hence "2.0.5-alpha".
> >>
> >> Arun, are you willing to start the 2.1.x name-space for your next release,
> >> so that 2.0.x-alpha can become an intermediate stabilization branch as Cos
> >> and Konst want?
> >
> > Let's get the facts straight, Matt, please: this "want" has been expressed 
> > in
> > the official vote here http://s.apache.org/ZMf Apparently, 2.0.5-alpha is
> > blocked now because of the another vote that hasn't been closed yet for
> > whatever reason. In order to unblock a number of releases in downstream
> > component I have moved forward with this release. Do you have any material
> > objections to the release that pursue this goal?
> >
> >> I just think that using four-number schemes was symptomatic of the
> >> near-forking we had back in the 0.20.xxx.y days, and I really don't want to
> >> go back there.  Especially since you could say that "0.20.xxx.y" is just
> >> three significant numbers, the leading zero being inconsequential.
> >
> > I dare to remind that forth part of the version is reserved - not in a
> > parallel universe, of course - for "patch level" aka bug fixes. It hardly 
> > can
> > be taken a sign of 'forking' by any definition.
> >
> > Cos
> >
> >> So, would you please consider using 2.0.5-alpha?
> >>
> >> As for the "2.0.5-SNAPSHOT" in the branch-2 versioning, that's standard
> >> usage.  Whoever makes the 2.0.5 release (or any "next" release) is expected
> >> to update the parent branch's SNAPSHOT default versioning, per
> >> HowToReleasePostMavenization#Branching,
> >> step 6.
> >>
> >> Thanks,
> >> --Matt
> >>
> >>
> >> On Thu, May 30, 2013 at 11:52 AM, Konstantin Boudnik  
> >> wrote:
> >>
> >> > On Thu, May 30, 2013 at 10:57AM, Arun C Murthy wrote:
> >> > > I see you just re-opened MAPREUDCE-5211.
> >> > >
> >> > > Why not include MAPREDUCE-5211 as well rather than create one release
> >> > per patch?
> >> >
> >> > Arun, it is unclear if MAPREDUCE-5211 has implications in 2.0.4 as per
> >> >
> >> > https://issues.apache.org/jira/browse/MAPREDUCE-5211?focusedCommentId=13670574&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13670574
> >> >
> >> > Hence, there's a good chance that it never will be backported. And I 
> >> > don't
> >> > have any plans to created 'a release per patch'.
> >> >
> >> > > Also, this is the first time we are seeing a four-numbered scheme in
> >> > Hadoop.
> >> > > Why not call this 2.0.5-alpha?
> >> >
> >> > There were precedents in four-numbered schemes before: 0.20.20[3-5].0
> >> > comes to
> >> > mind.
> >> >
> >> > As for 2.0.5-alpha: The release numbering games and votes that had
> >> > happened in
> >> > the last few weeks are very confusing. Some of them never been concluded,
> >> > the
> >> > branches are moved and artifact versions seem to be colliding. 2.0.4.x
> >> > seems
> >> > to work well for the stabilization purposes and it will allow to unblock
> >> > downstream and integration projects quickly.
> >> >
> >> > Cos
> >> >
> >> > > Arun
> >> > >
> >> > > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
> >> > >
> >> > > > All,
> >> > > >
> >> > > > I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha 
> >> > > > that
> >> > I would
> >> > > > like to release.
> >> > > >
> >> > > > This is a stabilization release that includes fixed for a couple a of
> >> > issues
> >> > > > discovered in the testing with BigTop 0.6.0 release candidate.
> >> > > >
> >> > > > The RC is available at:
> >> > http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
> >> > > > The RC tag in svn is here:
> >> > http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
> >> > > >
> >> > > > The maven artifacts are available via repository.apache.org.
> >> > > >
> >> > > > Please try the release bits and vote; the vote will run for the usual
> >> > 7 days.
> >> > > >
> >> > > > Thanks for your voting
> >> > > >  Cos
> >> > > >
> >> > >
> >> > >
> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Chris Douglas 
On Thu, May 30, 2013 at 3:25 PM, Konstantin Boudnik  wrote:
> There's no plans to release anything else at this point - this is a bug-fix
> release, as I pointed out on a numerous occasions. There's no new features -
> just 2 fixes.

If you're worried about extending the voting by a week, I don't think
anyone can reasonably object to a truncated schedule if the only
change is the version number. Downstream fixes discovered in Bigtop
are a sufficient reason for a patch release and I think we'd all like
them to become routine. Not just in 2.0.x, but in later release
branches.

> 2.0.5 matter became and still is too controversial at some point. The vote
> started by Arun to override the results of the Konstantin's vote never been
> closed.

For the nth time, neither release plan vote was binding. We recently
amended the bylaws to eliminate this confusion. There is no ambiguity
between votes when neither is in scope.

> The downstream projects are handing in the middle of the air because
> of that confusion.

Can we please ground our discussion when discussing compatibility and
bugs? Breathless alarm is not proportional to the severity, here.

> Have I missed something or you just called me a cheater and a lair right to 
> my face?

I called you neither. The prenominate votes were closed, counted, and
declared to be binding over objections. I'm annoyed that I have to
toggle my vote to prevent that tactic, but based on recent experience
I don't expect you to forgo it. I'd be happy to learn my caution is
unnecessary. -C

>> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy  
>> >> wrote:
>> >> > Why not include MAPREDUCE-4211 as well rather than create one release 
>> >> > per patch?
>> >>
>> >> From Cos's description, it sounded like these were backports of fixes
>> >> to help Sqoop2 and fix some build issues. If it's not just to fixup
>> >> leftover bugs in 2.0.4 *once* so downstream projects can integrate
>> >> against 2.0.4.1, and this a release series, then I've completely
>> >> misunderstood the purpose.
>> >>
>> >> Cos, are you planning 2.0.4.2?
>> >>
>> >> > Also, this is the first time we are seeing a four-numbered scheme in 
>> >> > Hadoop. Why not call this 2.0.5-alpha?
>> >>
>> >> Good point. Since it contains only backports from branch-2, it would
>> >> make sense for it to be an intermediate release.
>> >>
>> >> I shouldn't have to say this, but I'm changing my vote to -1 while we
>> >> work this out. -C
>> >>
>> >> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
>> >> >
>> >> >> All,
>> >> >>
>> >> >> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that 
>> >> >> I would
>> >> >> like to release.
>> >> >>
>> >> >> This is a stabilization release that includes fixed for a couple a of 
>> >> >> issues
>> >> >> discovered in the testing with BigTop 0.6.0 release candidate.
>> >> >>
>> >> >> The RC is available at: 
>> >> >> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
>> >> >> The RC tag in svn is here: 
>> >> >> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
>> >> >>
>> >> >> The maven artifacts are available via repository.apache.org.
>> >> >>
>> >> >> Please try the release bits and vote; the vote will run for the usual 
>> >> >> 7 days.
>> >> >>
>> >> >> Thanks for your voting
>> >> >>  Cos
>> >> >>
>> >> >
>> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Konstantin Boudnik 
On Thu, May 30, 2013 at 05:30PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 3:25 PM, Konstantin Boudnik  wrote:
> > There's no plans to release anything else at this point - this is a bug-fix
> > release, as I pointed out on a numerous occasions. There's no new features -
> > just 2 fixes.
> 
> If you're worried about extending the voting by a week, I don't think
> anyone can reasonably object to a truncated schedule if the only
> change is the version number. Downstream fixes discovered in Bigtop
> are a sufficient reason for a patch release and I think we'd all like
> them to become routine. Not just in 2.0.x, but in later release
> branches.

I have no issues of changing the version to 2.0.5-alpha and restarting to vote
for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote because
of the number change?

> > 2.0.5 matter became and still is too controversial at some point. The vote
> > started by Arun to override the results of the Konstantin's vote never been
> > closed.
> 
> For the nth time, neither release plan vote was binding. We recently
> amended the bylaws to eliminate this confusion. There is no ambiguity
> between votes when neither is in scope.

Does the result of bylaw vote nullifies the unfinished vote started by Arun?
Sorry, I am dense, apparently.

> > The downstream projects are handing in the middle of the air because
> > of that confusion.
> 
> Can we please ground our discussion when discussing compatibility and
> bugs? Breathless alarm is not proportional to the severity, here.

Good point. Can we limit the vote thread to the merits of the release then?

> > Have I missed something or you just called me a cheater and a lair right to 
> > my face?
> 
> I called you neither. The prenominate votes were closed, counted, and
> declared to be binding over objections. I'm annoyed that I have to
> toggle my vote to prevent that tactic, but based on recent experience
> I don't expect you to forgo it. I'd be happy to learn my caution is
> unnecessary. -C

That sound like adding an insult to injury, if my forth-language skills do not
mislead me.

Cos

> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy  
> >> >> wrote:
> >> >> > Why not include MAPREDUCE-4211 as well rather than create one release 
> >> >> > per patch?
> >> >>
> >> >> From Cos's description, it sounded like these were backports of fixes
> >> >> to help Sqoop2 and fix some build issues. If it's not just to fixup
> >> >> leftover bugs in 2.0.4 *once* so downstream projects can integrate
> >> >> against 2.0.4.1, and this a release series, then I've completely
> >> >> misunderstood the purpose.
> >> >>
> >> >> Cos, are you planning 2.0.4.2?
> >> >>
> >> >> > Also, this is the first time we are seeing a four-numbered scheme in 
> >> >> > Hadoop. Why not call this 2.0.5-alpha?
> >> >>
> >> >> Good point. Since it contains only backports from branch-2, it would
> >> >> make sense for it to be an intermediate release.
> >> >>
> >> >> I shouldn't have to say this, but I'm changing my vote to -1 while we
> >> >> work this out. -C
> >> >>
> >> >> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
> >> >> >
> >> >> >> All,
> >> >> >>
> >> >> >> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha 
> >> >> >> that I would
> >> >> >> like to release.
> >> >> >>
> >> >> >> This is a stabilization release that includes fixed for a couple a 
> >> >> >> of issues
> >> >> >> discovered in the testing with BigTop 0.6.0 release candidate.
> >> >> >>
> >> >> >> The RC is available at: 
> >> >> >> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
> >> >> >> The RC tag in svn is here: 
> >> >> >> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
> >> >> >>
> >> >> >> The maven artifacts are available via repository.apache.org.
> >> >> >>
> >> >> >> Please try the release bits and vote; the vote will run for the 
> >> >> >> usual 7 days.
> >> >> >>
> >> >> >> Thanks for your voting
> >> >> >>  Cos
> >> >> >>
> >> >> >
> >> >> >

Backwards compatibility of FileSystem interface.

2013-05-30 Thread Jay Vyas 
Hi :

Are FileSystem interfaces gauranteed to retain semantics of the old
FileSystem contract?

Im noticing that the new FileSystem uses the "CreateFlag" class, which
older ones did not, and I'm wondering wether the deprecation of some
FileSystem methods (i.e. createNonRecursive) will eventually be entirely
phased out.

This is in reference to some issues with HBASE and the createNonRecursive
implementation which varies across different hadoop versions.

-- 
Jay Vyas
http://jayunit100.blogspot.com

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Chris Douglas 
On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik  wrote:
> I have no issues of changing the version to 2.0.5-alpha and restarting to vote
> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote because
> of the number change?

+1 Sounds great.

> Does the result of bylaw vote nullifies the unfinished vote started by Arun?
> Sorry, I am dense, apparently.

Yes, nobody should feel bound by either vote. The bylaw change
clarifies that release plans are for RMs to solicit feedback and gauge
PMC support for an artifact, not pre-approvals for doing work.

> Can we limit the vote thread to the merits of the release then?

Happily.

> That sound like adding an insult to injury, if my forth-language skills do not
> mislead me.

They do mislead you, or I've expressed the point imprecisely. We can
take this offline. -C

>> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy  
>> >> >> wrote:
>> >> >> > Why not include MAPREDUCE-4211 as well rather than create one 
>> >> >> > release per patch?
>> >> >>
>> >> >> From Cos's description, it sounded like these were backports of fixes
>> >> >> to help Sqoop2 and fix some build issues. If it's not just to fixup
>> >> >> leftover bugs in 2.0.4 *once* so downstream projects can integrate
>> >> >> against 2.0.4.1, and this a release series, then I've completely
>> >> >> misunderstood the purpose.
>> >> >>
>> >> >> Cos, are you planning 2.0.4.2?
>> >> >>
>> >> >> > Also, this is the first time we are seeing a four-numbered scheme in 
>> >> >> > Hadoop. Why not call this 2.0.5-alpha?
>> >> >>
>> >> >> Good point. Since it contains only backports from branch-2, it would
>> >> >> make sense for it to be an intermediate release.
>> >> >>
>> >> >> I shouldn't have to say this, but I'm changing my vote to -1 while we
>> >> >> work this out. -C
>> >> >>
>> >> >> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
>> >> >> >
>> >> >> >> All,
>> >> >> >>
>> >> >> >> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha 
>> >> >> >> that I would
>> >> >> >> like to release.
>> >> >> >>
>> >> >> >> This is a stabilization release that includes fixed for a couple a 
>> >> >> >> of issues
>> >> >> >> discovered in the testing with BigTop 0.6.0 release candidate.
>> >> >> >>
>> >> >> >> The RC is available at: 
>> >> >> >> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
>> >> >> >> The RC tag in svn is here: 
>> >> >> >> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
>> >> >> >>
>> >> >> >> The maven artifacts are available via repository.apache.org.
>> >> >> >>
>> >> >> >> Please try the release bits and vote; the vote will run for the 
>> >> >> >> usual 7 days.
>> >> >> >>
>> >> >> >> Thanks for your voting
>> >> >> >>  Cos
>> >> >> >>
>> >> >> >
>> >> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Alejandro Abdelnur 
Konstantin, Cos,

As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
housekeeping as you work the new RC.

* rename the svn branch
* update the versions in the POMs
* update the CHANGES.txt in trunk, branch-2 and the release branch
* change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
version, change the fix version of the 2 JIRAs that make the RC

Thanks.


On Thu, May 30, 2013 at 6:18 PM, Chris Douglas  wrote:

> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik 
> wrote:
> > I have no issues of changing the version to 2.0.5-alpha and restarting
> to vote
> > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> because
> > of the number change?
>
> +1 Sounds great.
>
> > Does the result of bylaw vote nullifies the unfinished vote started by
> Arun?
> > Sorry, I am dense, apparently.
>
> Yes, nobody should feel bound by either vote. The bylaw change
> clarifies that release plans are for RMs to solicit feedback and gauge
> PMC support for an artifact, not pre-approvals for doing work.
>
> > Can we limit the vote thread to the merits of the release then?
>
> Happily.
>
> > That sound like adding an insult to injury, if my forth-language skills
> do not
> > mislead me.
>
> They do mislead you, or I've expressed the point imprecisely. We can
> take this offline. -C
>
> >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> a...@hortonworks.com> wrote:
> >> >> >> > Why not include MAPREDUCE-4211 as well rather than create one
> release per patch?
> >> >> >>
> >> >> >> From Cos's description, it sounded like these were backports of
> fixes
> >> >> >> to help Sqoop2 and fix some build issues. If it's not just to
> fixup
> >> >> >> leftover bugs in 2.0.4 *once* so downstream projects can integrate
> >> >> >> against 2.0.4.1, and this a release series, then I've completely
> >> >> >> misunderstood the purpose.
> >> >> >>
> >> >> >> Cos, are you planning 2.0.4.2?
> >> >> >>
> >> >> >> > Also, this is the first time we are seeing a four-numbered
> scheme in Hadoop. Why not call this 2.0.5-alpha?
> >> >> >>
> >> >> >> Good point. Since it contains only backports from branch-2, it
> would
> >> >> >> make sense for it to be an intermediate release.
> >> >> >>
> >> >> >> I shouldn't have to say this, but I'm changing my vote to -1
> while we
> >> >> >> work this out. -C
> >> >> >>
> >> >> >> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
> >> >> >> >
> >> >> >> >> All,
> >> >> >> >>
> >> >> >> >> I have created a release candidate (rc0) for
> hadoop-2.0.4.1-alpha that I would
> >> >> >> >> like to release.
> >> >> >> >>
> >> >> >> >> This is a stabilization release that includes fixed for a
> couple a of issues
> >> >> >> >> discovered in the testing with BigTop 0.6.0 release candidate.
> >> >> >> >>
> >> >> >> >> The RC is available at:
> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
> >> >> >> >> The RC tag in svn is here:
> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
> >> >> >> >>
> >> >> >> >> The maven artifacts are available via repository.apache.org.
> >> >> >> >>
> >> >> >> >> Please try the release bits and vote; the vote will run for
> the usual 7 days.
> >> >> >> >>
> >> >> >> >> Thanks for your voting
> >> >> >> >>  Cos
> >> >> >> >>
> >> >> >> >
> >> >> >> >
>



-- 
Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Konstantin Shvachko 
Sounds like a plan.

Thanks,
--Konst


On Thu, May 30, 2013 at 8:41 PM, Alejandro Abdelnur wrote:

> Konstantin, Cos,
>
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
>
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC
>
> Thanks.
>
>
> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas 
> wrote:
>
> > On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik 
> > wrote:
> > > I have no issues of changing the version to 2.0.5-alpha and restarting
> > to vote
> > > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> > because
> > > of the number change?
> >
> > +1 Sounds great.
> >
> > > Does the result of bylaw vote nullifies the unfinished vote started by
> > Arun?
> > > Sorry, I am dense, apparently.
> >
> > Yes, nobody should feel bound by either vote. The bylaw change
> > clarifies that release plans are for RMs to solicit feedback and gauge
> > PMC support for an artifact, not pre-approvals for doing work.
> >
> > > Can we limit the vote thread to the merits of the release then?
> >
> > Happily.
> >
> > > That sound like adding an insult to injury, if my forth-language skills
> > do not
> > > mislead me.
> >
> > They do mislead you, or I've expressed the point imprecisely. We can
> > take this offline. -C
> >
> > >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> > >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> > a...@hortonworks.com> wrote:
> > >> >> >> > Why not include MAPREDUCE-4211 as well rather than create one
> > release per patch?
> > >> >> >>
> > >> >> >> From Cos's description, it sounded like these were backports of
> > fixes
> > >> >> >> to help Sqoop2 and fix some build issues. If it's not just to
> > fixup
> > >> >> >> leftover bugs in 2.0.4 *once* so downstream projects can
> integrate
> > >> >> >> against 2.0.4.1, and this a release series, then I've completely
> > >> >> >> misunderstood the purpose.
> > >> >> >>
> > >> >> >> Cos, are you planning 2.0.4.2?
> > >> >> >>
> > >> >> >> > Also, this is the first time we are seeing a four-numbered
> > scheme in Hadoop. Why not call this 2.0.5-alpha?
> > >> >> >>
> > >> >> >> Good point. Since it contains only backports from branch-2, it
> > would
> > >> >> >> make sense for it to be an intermediate release.
> > >> >> >>
> > >> >> >> I shouldn't have to say this, but I'm changing my vote to -1
> > while we
> > >> >> >> work this out. -C
> > >> >> >>
> > >> >> >> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
> > >> >> >> >
> > >> >> >> >> All,
> > >> >> >> >>
> > >> >> >> >> I have created a release candidate (rc0) for
> > hadoop-2.0.4.1-alpha that I would
> > >> >> >> >> like to release.
> > >> >> >> >>
> > >> >> >> >> This is a stabilization release that includes fixed for a
> > couple a of issues
> > >> >> >> >> discovered in the testing with BigTop 0.6.0 release
> candidate.
> > >> >> >> >>
> > >> >> >> >> The RC is available at:
> > http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
> > >> >> >> >> The RC tag in svn is here:
> >
> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
> > >> >> >> >>
> > >> >> >> >> The maven artifacts are available via repository.apache.org.
> > >> >> >> >>
> > >> >> >> >> Please try the release bits and vote; the vote will run for
> > the usual 7 days.
> > >> >> >> >>
> > >> >> >> >> Thanks for your voting
> > >> >> >> >>  Cos
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> >
> >
>
>
>
> --
> Alejandro
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Konstantin Boudnik 
Thanks Alejandro,

that's what my plan for the morning. Thanks for putting together the
check-list - would be easier for me not to miss anything. I am aiming to have
the bits out by noon or so. Appreciate the help!

Cos

On Thu, May 30, 2013 at 08:41PM, Alejandro Abdelnur wrote:
> Konstantin, Cos,
> 
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
> 
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC
> 
> Thanks.
> 
> 
> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas  wrote:
> 
> > On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik 
> > wrote:
> > > I have no issues of changing the version to 2.0.5-alpha and restarting
> > to vote
> > > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> > because
> > > of the number change?
> >
> > +1 Sounds great.
> >
> > > Does the result of bylaw vote nullifies the unfinished vote started by
> > Arun?
> > > Sorry, I am dense, apparently.
> >
> > Yes, nobody should feel bound by either vote. The bylaw change
> > clarifies that release plans are for RMs to solicit feedback and gauge
> > PMC support for an artifact, not pre-approvals for doing work.
> >
> > > Can we limit the vote thread to the merits of the release then?
> >
> > Happily.
> >
> > > That sound like adding an insult to injury, if my forth-language skills
> > do not
> > > mislead me.
> >
> > They do mislead you, or I've expressed the point imprecisely. We can
> > take this offline. -C
> >
> > >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> > >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> > a...@hortonworks.com> wrote:
> > >> >> >> > Why not include MAPREDUCE-4211 as well rather than create one
> > release per patch?
> > >> >> >>
> > >> >> >> From Cos's description, it sounded like these were backports of
> > fixes
> > >> >> >> to help Sqoop2 and fix some build issues. If it's not just to
> > fixup
> > >> >> >> leftover bugs in 2.0.4 *once* so downstream projects can integrate
> > >> >> >> against 2.0.4.1, and this a release series, then I've completely
> > >> >> >> misunderstood the purpose.
> > >> >> >>
> > >> >> >> Cos, are you planning 2.0.4.2?
> > >> >> >>
> > >> >> >> > Also, this is the first time we are seeing a four-numbered
> > scheme in Hadoop. Why not call this 2.0.5-alpha?
> > >> >> >>
> > >> >> >> Good point. Since it contains only backports from branch-2, it
> > would
> > >> >> >> make sense for it to be an intermediate release.
> > >> >> >>
> > >> >> >> I shouldn't have to say this, but I'm changing my vote to -1
> > while we
> > >> >> >> work this out. -C
> > >> >> >>
> > >> >> >> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
> > >> >> >> >
> > >> >> >> >> All,
> > >> >> >> >>
> > >> >> >> >> I have created a release candidate (rc0) for
> > hadoop-2.0.4.1-alpha that I would
> > >> >> >> >> like to release.
> > >> >> >> >>
> > >> >> >> >> This is a stabilization release that includes fixed for a
> > couple a of issues
> > >> >> >> >> discovered in the testing with BigTop 0.6.0 release candidate.
> > >> >> >> >>
> > >> >> >> >> The RC is available at:
> > http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
> > >> >> >> >> The RC tag in svn is here:
> > http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
> > >> >> >> >>
> > >> >> >> >> The maven artifacts are available via repository.apache.org.
> > >> >> >> >>
> > >> >> >> >> Please try the release bits and vote; the vote will run for
> > the usual 7 days.
> > >> >> >> >>
> > >> >> >> >> Thanks for your voting
> > >> >> >> >>  Cos
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> >
> >
> 
> 
> 
> -- 
> Alejandro


signature.asc
Description: Digital signature

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

2013-05-30 Thread Vinod Kumar Vavilapalli 

This started out as something and ended up as something else altogether.

In any case, I think you should give a fresh heads up outside this thread.

There are a bunch of commits and merges happening into branch-2 and thus 2.0.5, 
so it'll be safe to have an explicit hold-off/all-clear signaling. Otherwise 
you'll be racing with others on CHANGES.txt commits and the JIRA version set.

Thanks,
+Vinod


On May 30, 2013, at 10:50 PM, Konstantin Boudnik wrote:

> Thanks Alejandro,
> 
> that's what my plan for the morning. Thanks for putting together the
> check-list - would be easier for me not to miss anything. I am aiming to have
> the bits out by noon or so. Appreciate the help!
> 
> Cos
> 
> On Thu, May 30, 2013 at 08:41PM, Alejandro Abdelnur wrote:
>> Konstantin, Cos,
>> 
>> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
>> housekeeping as you work the new RC.
>> 
>> * rename the svn branch
>> * update the versions in the POMs
>> * update the CHANGES.txt in trunk, branch-2 and the release branch
>> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
>> version, change the fix version of the 2 JIRAs that make the RC
>> 
>> Thanks.
>> 
>> 
>> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas  wrote:
>> 
>>> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik 
>>> wrote:
 I have no issues of changing the version to 2.0.5-alpha and restarting
>>> to vote
 for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
>>> because
 of the number change?
>>> 
>>> +1 Sounds great.
>>> 
 Does the result of bylaw vote nullifies the unfinished vote started by
>>> Arun?
 Sorry, I am dense, apparently.
>>> 
>>> Yes, nobody should feel bound by either vote. The bylaw change
>>> clarifies that release plans are for RMs to solicit feedback and gauge
>>> PMC support for an artifact, not pre-approvals for doing work.
>>> 
 Can we limit the vote thread to the merits of the release then?
>>> 
>>> Happily.
>>> 
 That sound like adding an insult to injury, if my forth-language skills
>>> do not
 mislead me.
>>> 
>>> They do mislead you, or I've expressed the point imprecisely. We can
>>> take this offline. -C
>>> 
 On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
>>> a...@hortonworks.com> wrote:
>> Why not include MAPREDUCE-4211 as well rather than create one
>>> release per patch?
> 
> From Cos's description, it sounded like these were backports of
>>> fixes
> to help Sqoop2 and fix some build issues. If it's not just to
>>> fixup
> leftover bugs in 2.0.4 *once* so downstream projects can integrate
> against 2.0.4.1, and this a release series, then I've completely
> misunderstood the purpose.
> 
> Cos, are you planning 2.0.4.2?
> 
>> Also, this is the first time we are seeing a four-numbered
>>> scheme in Hadoop. Why not call this 2.0.5-alpha?
> 
> Good point. Since it contains only backports from branch-2, it
>>> would
> make sense for it to be an intermediate release.
> 
> I shouldn't have to say this, but I'm changing my vote to -1
>>> while we
> work this out. -C
> 
>> On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
>> 
>>> All,
>>> 
>>> I have created a release candidate (rc0) for
>>> hadoop-2.0.4.1-alpha that I would
>>> like to release.
>>> 
>>> This is a stabilization release that includes fixed for a
>>> couple a of issues
>>> discovered in the testing with BigTop 0.6.0 release candidate.
>>> 
>>> The RC is available at:
>>> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/
>>> The RC tag in svn is here:
>>> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0
>>> 
>>> The maven artifacts are available via repository.apache.org.
>>> 
>>> Please try the release bits and vote; the vote will run for
>>> the usual 7 days.
>>> 
>>> Thanks for your voting
>>> Cos
>>> 
>> 
>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Alejandro