Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
MapReduce >> mail # dev >> [Vote] Merge branch-trunk-win to trunk


+
Suresh Srinivas 2013-02-26, 22:55
+
Robert Evans 2013-02-27, 16:17
+
Eli Collins 2013-02-27, 19:56
+
Suresh Srinivas 2013-02-27, 22:54
+
Todd Lipcon 2013-02-27, 23:43
Copy link to this message
-
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 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
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Vote] Merge branch-trunk-win to trunk

On Wed, Feb 27, 2013 at 2:54 PM, Suresh Srinivas <[EMAIL PROTECTED]>wrote:

> 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
> Some questions have been raised about would new features need to be
> supported on both the platforms. Yes. I do not see a reason why
> features cannot work on both the platforms, with the exception of
> platform specific optimizations. This what Java gives us.
>
>
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
>
> On Wed, Feb 27, 2013 at 11:56 AM, Eli Collins <[EMAIL PROTECTED]> wrote:
>
> > 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 Windows support is implemented first.
> >
> > Is there a jira for resolving the outstanding TODOs in the code base

Todd Lipcon
Software Engineer, Cloudera
+
John Gordon 2013-02-28, 11:25
+
Chris Nauroth 2013-02-28, 16:45
+
Robert Evans 2013-02-28, 19:29
+
Chris Nauroth 2013-02-28, 19:50
+
Harsh J 2013-02-27, 19:20
+
Konstantin Shvachko 2013-03-02, 03:14
+
Konstantin Shvachko 2013-03-01, 20:18
+
Chris Douglas 2013-03-01, 21:28
+
Konstantin Shvachko 2013-03-01, 21:57
+
Chris Douglas 2013-03-02, 00:57
+
Konstantin Boudnik 2013-03-01, 23:47
+
Suresh Srinivas 2013-03-02, 01:55
+
Konstantin Boudnik 2013-03-02, 03:33
+
Matt Foley 2013-03-02, 20:32
+
Konstantin Shvachko 2013-03-03, 03:32
+
Matt Foley 2013-03-03, 19:08
+
Konstantin Shvachko 2013-03-03, 20:16
+
Bikas Saha 2013-03-01, 17:55
+
Konstantin Boudnik 2013-03-01, 01:04
+
Ramya Sunil 2013-03-01, 00:59
+
Suresh Srinivas 2013-03-06, 19:50
+
Andrew Purtell 2013-03-25, 20:36
+
Suresh Srinivas 2013-03-26, 00:08
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB