On Mon, Jan 17, 2011 at 9:04 PM, Nigel Daley <nda...@mac.com> wrote: > Good questions. Keep them coming! I'll compile a list so we can start an > FAQ on this. > >> # Is project split a goal for hadoop in the future (even though we are not >> ready yet?). If it is, then putting projects back together might result in >> tight dependencies between the project. Ho do we avoid it? > > > Note, we're not putting them back together. This is NOT a cmd-Z (ctrl-Z) on > the project split. It's putting them back under one trunk, but as separate > projects underneath that. IMO this is a relatively small change in the > universe of undo-the-project-split possibilities.
Yes, the three projects would still build separately. However, it would be useful to have a small top-level script to produce a single artifact, like https://issues.apache.org/jira/browse/HADOOP-6342 and https://issues.apache.org/jira/browse/HADOOP-6846. > >> # The committer list for each of the sub project today is different. How do >> we reconcile them? > > I'd like to keep that issue out of this change if at all possible. I > recommend for now we keep the status quo. Thus, even though all committers > may technically have permission to commit to all 3 project trees (can someone > confirm that?), we would need to rely on the honor system that committers > will only commit to their project trees. That's right - we don't have fine-grained commit access on the Hadoop tree, so we don't need to change anything here. Tom > > Cheers, > Nige > > On Jan 14, 2011, at 12:00 PM, Suresh Srinivas wrote: > >> I like the idea of merging projects together. It save a lot of time. >> >> However, I would like to see a detailed proposal on how this will be done >> and discussions on it, before moving forward on this. If this work is done, >> need clear messages to the developers on what has changed, and how >> development process is affected. These details were missing when project >> split was done, causing great deal of confusion and pain. >> >> We should also address the following: >> # Is project split a goal for hadoop in the future (even though we are not >> ready yet?). If it is, then putting projects back together might result in >> tight dependencies between the project. Ho do we avoid it? >> # The committer list for each of the sub project today is different. How do >> we reconcile them? >> >> >> On 1/14/11 11:53 AM, "Tsz Wo (Nicholas), Sze" >> <s29752-hadoopgene...@yahoo.com> wrote: >> >> This is a kind of an incompatible change: all the developers, QAs, release >> engineers and users have to change their local settings and scripts for this >> change. Moreover, there are documentations, web pages and existing tools >> using >> the Apache svn URLs. So it is a huge impact. I am conservative on this >> since, >> as Konstantin mentioned, we risk to get into the same mess, and it will >> create >> more work for the community. >> >> Why do we want to enforce the releases as a unit, given that the long term >> target is to release these 3 projects independently? >> >> Nicholas >> >> >> >> >> >> ________________________________ >> From: Nigel Daley <nda...@mac.com> >> To: general@hadoop.apache.org >> Sent: Fri, January 14, 2011 11:21:25 AM >> Subject: Re: [DISCUSS] Move project split down a level >> >> >> On Jan 14, 2011, at 11:16 AM, Tsz Wo (Nicholas), Sze wrote: >> >>> Hi Nigel, >>> >>>> As I look more at the impact of the common/MR/HDFS project split on what >>>> and how we release Hadoop, I feel like the split needs an adjustment. Many >>>> folks I've talked to agree that the project split has caused us a splitting >>>> headache. I think 1 relatively small change could alleviate some of that. >>> >>> Could you elaborate your idea on how the proposed changes would help? What >>> the >>> >>> problems are being addressed? It is not clear to me. >> >> Critical in my mind was my statement: "We're a long way from releasing these >> 3 >> projects independently. Given that, they should be branched and released as >> a >> unit." This can not be enforced given the current svn layout. Other's can >> weigh >> in with additional thoughts. >> >>> You are right that the change is small but the impact is huge. We should >>> first >>> >>> understand what we are getting from the changes before doing it. >> >> What do you see as the huge impact? >> >> Nige >> > >
