+1 (non-binding)

I am really glad to see this happening! As people already mentioned, this has been a great engineering effort involving many people!
Folks raised some valid concerns below and I thought it would be good to share my 2 cents. In my opinion, we don't have to solve all these problems right now. As we move forward with two platforms, we can start addressing one problem at a time and incrementally improve. In the first iteration, maintaining Hadoop on Windows could be just everyone trying to do their best effort (make sure Jenkins build succeeds at least). We already have people who are building/running trunk on Windows daily, so they would jump in and fix problems as needed (we've been doing this in branch-trunk-win for a while now). Although I see that the problems could arise with platform specific features/optimizations, I don't think these are frequent, so in most cases everything will just work. Merging the two branches sooner rather than later does seems like the right thing to do if the ultimate goal is to have Hadoop on both platforms. Now that the port has completed, we will have people in Microsoft (and elsewhere) wanting to contribute features/improvements to the trunk branch. A separate branch would just make things more difficult and confusing for everyone :) Hope this makes sense.

-----Original Message-----
From: Todd Lipcon [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 27, 2013 3:43 PM
Subject: Re: [Vote] Merge branch-trunk-win to trunk

On Wed, Feb 27, 2013 at 2:54 PM, Suresh Srinivas <[EMAIL PROTECTED]>wrote:
I'm concerned about the above. Personally, I don't have access to any Windows boxes with development tools, and I know nothing about developing on Windows. The only Windows I run is an 8GB VM with 1 GB RAM allocated, for powerpoint :)

If I submit a patch and it gets -1 "tests failed" on the Windows slave, how am I supposed to proceed?

I think a reasonable compromise would be that the tests should always
*build* on Windows before commit, and contributors should do their best to look at the test logs for any Windows-specific failures. But, beyond looking at the logs, a "-1 Tests failed on windows" should not block a commit.

Those contributors who are interested in Windows being a first-class platform should be responsible for watching the Windows builds and debugging/fixing any regressions that might be Windows-specific.

I also think the KDE model that Harsh pointed out is an interesting one -- ie the idea that we would not merge windows support to trunk, but rather treat is as a "parallel code line" which lives in the ASF and has its own builds and releases. The windows team would periodically merge trunk->win to pick up any new changes, and do a separate test/release process. I'm not convinced this is the best idea, but worth discussion of pros and cons.


Todd Lipcon
Software Engineer, Cloudera