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 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
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
> > (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
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