To avoid any bias to the existing code and make the same mistakes we should just delete trunk completely.

Attached it is a script that deletes everything.

+1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12570034/HADOOP-9448.patch
against trunk revision .

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 3 new or modified test files.

+1 javac. The applied patch does not increase the total number of javac compiler warnings.

+1 javadoc. The javadoc tool did not generate any warning messages.

+1 eclipse:eclipse. The patch built with eclipse:eclipse.

+1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

+1 release audit. The applied patch does not increase the total number of release audit warnings.

+1 core tests. The patch does not include tests but it is OK.

+1 contrib tests. The patch passed contrib unit tests.

Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3210//testReport/
Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3210//console

This message is automatically generated.

Good idea. I've heard several users and potential contributors complain about things.

+1, the patch looks good to me.

Committed to trunk. I'll wait for a few minutes and then I'll commit to branch-2 and branch-1.

In case it wasn't clear, this patch removes all the code from the repo so that we can have a blank slate to reimplement Hadoop from scratch

Please commit this to branch-0.23 as well. TIA

Instead of reimplementing from a blank slate, I propose we split each Maven module into its own TLP. We can simply svn cp everything from trunk into new repositories for each new TLP and let them figure out what to keep and what to drop from their respective project.

+1 - great idea.

Instead of reimplementing from a blank slate, I propose we split each Maven module into its own TLP. We can simply svn cp everything from trunk into new repositories for each new TLP and let them figure out what to keep and what to drop from their respective project.

Before we do that, we should probably decide if we want interface-implementation or abstract class - extension.

I would like to warn that if this patch is applied, hadoop will be in violation of a patent pending NullDB product launched today. Would someone from ASF legal comment ? http://www.neotechnology.com/2013/04/neo-technologys-announces-new-database-nulldb/

Can we consider C# and Mono for this reimplementation.

I don't see any tests here. Before deleting them can you move them all to JUnit4 and add @Timeout attributes. thanks.

Can we consider C# and Mono for this reimplementation.

I think it must be Haskell. Then the solution for application problems will present at compile time.

I propose we split each Maven module into its own TLP....

I thought we were going with Ant this time. If people are not sure about how well ant will work, we could covert hadoop from Maven to Ant first and get a feel of it, before deleting code. I believe Alejandro will be the best person to tackle this.

The important thing is that SOMETHING gets split into two projects as a result. If there's nothing left to split, I think Hadoop is complete and we should all move on.

Based on patch size, you just became the largest contributor to Hadoop.

way to go. BTW the patch is an abridged version as the original one was 70MB and the maximum JIRA upload is 10MB.

About time, make way for hadoop.js !

Recommend close for dupe, see YARN-1

Patch is failing to apply. Computer is questioning my actions. Dog is barking. Can't sleep.
....
Actually patch just finished applying. All unit tests passed. +One.

+1,LGTM

This is too big a change. The proposal is completely vague too, please put forward a concrete proposal and then perhaps file specific tasks/tickets. Or start a new project altogether.

Closing this as won't fix. If you insist, we can reopen this next year same time.

PS: Fun's over boys (in all time-zones, dunno much about how time's tracked on other planets).