hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Developing cross-component patches post-split
Date Wed, 01 Jul 2009 20:44:33 GMT
Hey all,

I think there's general confusion right now about how the development
process is supposed to work now that the project split has taken place. Or,
at least, I am generally confused :) Here are a couple questions I have

- Whenever a task will need to touch both Common and one of the components
(Mapred/HDFS) should there be two JIRAs or is it sufficient to have just one
"HADOOP" JIRA with separate patches uploaded for the two repositories?

- If we're to do two separate JIRAs, is the best bet to use JIRA's "linking"
feature to show the dependency between them? I often have HDFS or Mapred
changes that require a small addition or change to o.a.h.util, for example.
On its own, that util change might look silly (and "unused") but if we don't
make it easy to put stuff in util, we're going to end up with a lot of code
duplication between MR and HDFS.

- When we have one of these cross-project changes, how are we supposed to do
builds? It looks like right now there's a core 21-dev jar checked into the
MR and HDFS repositories. Does this mean that any time we have a
cross-component change we'll need to get it committed to Common, do a jar
build of common, copy that new jar into the component, and include that as
part of the component commit? This seems very ugly to me, and completely
inefficient while doing development. It will also make our git repository
sizes baloon like crazy since we'll have hundreds of different versions of
the core dev jar.

If someone could write up some kind of "post-split transition guide" on the
Wiki I think that would be generally appreciated.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message