Andrew, this used to be on all -dev lists. Let's keep it that way.
To the point.
Does this mean that people are silently porting windows changes to branch-2?
New features on a branch should be voted first, no?
Thanks,
--Konstantin
On Mon, Mar 25, 2013 at 1:36 PM, Andrew Purtell
Adding other mailing lists I missed earlier.
Cos,
There is progress being made on that ticket. Also it has nothing to do with
that.
Please follow the discussion here and why this happened due to an invalid
commit that was reverted -
On Mon, Mar 4, 2013 at 12:22 PM, Matt Foley mfo...@hortonworks.com wrote:
Konstantine, you have voted -1, and stated some requirements before you'll
withdraw that -1. As I plan to do work to fulfill those requirements, I
want to make sure that what I'm proposing will, in fact, satisfy you.
+1 on the merge.
I am glad we agreed.
Having Jira to track the CI effort is a good idea.
Thanks,
--Konstantin
On Mon, Mar 4, 2013 at 3:29 PM, Matt Foley mfo...@hortonworks.com wrote:
Thanks. I agree Windows -1's in test-patch should not block commits.
--Matt
On Mon, Mar 4, 2013 at 2:30
[mailto:mahesw...@huawei.com]
Sent: Thursday, February 28, 2013 9:20 PM
To: hdfs-...@hadoop.apache.org; common-...@hadoop.apache.org
Cc: yarn-dev@hadoop.apache.org; mapreduce-...@hadoop.apache.org
Subject: RE: [Vote] Merge branch-trunk-win to trunk
+1 (non-binding)
Thanks a lot for the work done by Suresh
Commitment is a good thing.
I think the two builds that I proposed are a prerequisite for Win support.
If we commit windows patch people will start breaking it the next day.
Which we wont know without the nightly build and wont be able to fix
without the on-demand one.
Making two builds is less
On Fri, Mar 1, 2013 at 1:57 PM, Konstantin Shvachko
shv.had...@gmail.com wrote:
Commitment is a good thing.
I think the two builds that I proposed are a prerequisite for Win support.
If we commit windows patch people will start breaking it the next day.
Which we wont know without the nightly
On Mar 1, 2013, at 1:57 PM, Konstantin Shvachko wrote:
Commitment is a good thing.
I think the two builds that I proposed are a prerequisite for Win support.
If we commit windows patch people will start breaking it the next day.
Which we wont know without the nightly build and wont be able
-...@hadoop.apache.org; common-...@hadoop.apache.org
Cc: yarn-dev@hadoop.apache.org; hdfs-...@hadoop.apache.org
Subject: RE: [Vote] Merge branch-trunk-win to trunk
+1 (non-binding)
I am really glad to see this happening! As people already mentioned, this has
been a great engineering effort
+1 non-binding
Nice to see that this work is going to trunk.
Raja Aluri
On Tue, Feb 26, 2013 at 2:55 PM, Suresh Srinivas sur...@hortonworks.comwrote:
I had posted heads up about merging branch-trunk-win to trunk on Feb 8th. I
am happy to announce that we are ready for the merge.
Here is a
-Original Message-
From: Ivan Mitic [mailto:iva...@microsoft.com]
Sent: Wednesday, February 27, 2013 6:32 PM
To: mapreduce-...@hadoop.apache.org; common-...@hadoop.apache.org
Cc: yarn-dev@hadoop.apache.org; hdfs-...@hadoop.apache.org
Subject: RE: [Vote] Merge branch-trunk-win to trunk
On Thu, Feb 28, 2013 at 03:08PM, sanjay Radia wrote:
+1
Java has done the bulk of the work in making Hadoop multi-platform.
Windows specific code is a tiny percentage of the code.
Jeninks support for windows is going help us keep the platform portable going
forward.
I expect that the vast
+1 for the merge.
As someone who has been testing the code for many months now, both on
singlenode and multinode clusters, I am very confident about the stability
and the quality of the code. I have run several regression tests to verify
distributed cache, streaming, compression, capacity
+1
Java has done the bulk of the work in making Hadoop multi-platform.
Windows specific code is a tiny percentage of the code.
Jeninks support for windows is going help us keep the platform portable going
forward.
I expect that the vast majority of new commits have no problems. I propose
that
After this is merged in is Windows still going to be a second class
citizen but happens to work for more than just development or is it a
fully supported platform where if something breaks it can block a release?
How do we as a community intend to keep Windows support from breaking?
We don't have
Similar personal concern as Robert: Does this bring about a
development process change? Do new features all need to work on
Windows as well to go into trunk (i.e. immediately or eventually,
either way requires a new policy for all of us devs)? Not that anyone
would be avoiding doing that, I just
Bobby raises some good questions. A related one, since most current
developers won't add Windows support for new features that are
platform specific is it assumed that Windows development will either
lag or will people actively work on keeping Windows up with the
latest? And vice versa in case
Thanks for raising good questions.
Currently the merge patch passes all the tests on Linux, hence
the proposal for merging the patch to trunk. But as Bobby, Harsh
and Eli pointed out, before declaring support for Windows, we need the
discussion on the following:
1. Precommit and development
+1 non-binding.
I have extensively tested this on both Windows and Linux over the last few
months.
Thanks,
-Arpit
On Wed, Feb 27, 2013 at 11:56 AM, Eli Collins e...@cloudera.com wrote:
Bobby raises some good questions. A related one, since most current
developers won't add Windows support
On Wed, Feb 27, 2013 at 2:54 PM, Suresh Srinivas sur...@hortonworks.comwrote:
With that we need to decide how our precommit process looks.
My inclination is to wait for +1 from precommit builds on
both the platforms to ensure no issues are introduced.
Thoughts?
2. Feature development impact
Cc: yarn-dev@hadoop.apache.org; hdfs-...@hadoop.apache.org;
mapreduce-...@hadoop.apache.org
Subject: Re: [Vote] Merge branch-trunk-win to trunk
On Wed, Feb 27, 2013 at 2:54 PM, Suresh Srinivas sur...@hortonworks.comwrote:
With that we need to decide how our precommit process looks.
My
21 matches
Mail list logo
