I know of very few to nearly zero number of patches in mapreduce that
touch HDFS also. And vice versa. The common case is of patches that
touch both common and mapreduce or common and hdfs. I am one of those
who has access to mapreduce project but not to common project and find
more than 50% of the patches that fall into this category.
(*) May be then we should simply knock off the separate list for common
project and maintain separate lists for mapreduce and hdfs members of
which will automatically have karma for the common project.
As for the separation of the repositories, I personally felt separation
of mapreduce from hdfs helped focusing on things a lot better. The last
gasp work done for 0.21, mostly by Tom, did help a lot in decoupling the
projects. Common is the hot point, sure, but as others noted, that is a
separate discussion.
My few cents.
+vinod
On Wednesday 11 August 2010 10:34 AM, Arun C Murthy wrote:
On Aug 9, 2010, at 9:26 AM, Doug Cutting wrote:
On 08/08/2010 12:21 PM, Arun C Murthy wrote:
This of course begs a larger question - should we just merge Common,
HDFS& Map-Reduce together and be done with?
I think there's still a reasonable long-term goal to split MapReduce
from HDFS, so that they can release separately and are maintained by
separate teams. So I believe a strong division of these code trees
and
release artifacts should remain.
It is clear from the comments on this thread that the move to split
HDFS and Map-Reduce into separate projects has been a mixed bag -
maybe a net negative.
It has caused issues we as a community haven't dealt well with.
So, we need to make a decision - do we stick the course, get through
the painful process and emerge stronger or do we take a step back and
regress a decision we made back then? The current proposal to merge
committer lists seems like a regression.
Arun
