Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

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

Copy link to this message
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

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.

> 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
> > (similar to HDFS-2148)?  Looks like this merge doesn't introduce many
> > which is great (just did a quick diff and grep).
> >
> > Thanks,
> > Eli
> >
> > On Wed, Feb 27, 2013 at 8:17 AM, Robert Evans <[EMAIL PROTECTED]>
> wrote:
> > > 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 any Jenkins slaves to be able to run nightly tests to
> > > validate everything still compiles/runs.  This is not a blocker for me
> > > because we often rely on individuals and groups to test Hadoop, but I
> do
> > > think we need to have this discussion before we put it in.
> > >
> > > --Bobby
> > >
> > > On 2/26/13 4:55 PM, "Suresh Srinivas" <[EMAIL PROTECTED]> wrote:
> > >
> > >>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 brief recap on the highlights of the work done:
> > >>- Command-line scripts for the Hadoop surface area
> > >>- Mapping the HDFS permissions model to Windows
> > >>- Abstracted and reconciled mismatches around differences in Path
> > >>semantics
> > >>in Java and Windows
> > >>- Native Task Controller for Windows
> > >>- Implementation of a Block Placement Policy to support cloud
> > >>environments,
> > >>more specifically Azure.
> > >>- Implementation of Hadoop native libraries for Windows (compression

Todd Lipcon
Software Engineer, Cloudera