The QA-bot unfortunately can still only deal with single-project patches. I think there's an open JIRA to allow it to do cross-project tests.
I think for this patch, let's stick with the old way. We can do a single commit when it's committed, but review-wise and QA-bot wise, separate JIRAs is probably the way to go until we figure out a proper way to do these. -Todd On Sat, Jul 2, 2011 at 10:03 AM, Travis Crawford <traviscrawf...@gmail.com>wrote: > Hey hadoop gurus - > > With the merged repo, is the process for submitting patches that span > repos still one patch per repo? Is submitting a single patch with > changes to common, hdfs, and mapreduce acceptable post-merge? > > If so, I can update the "Changes that span projects" section of > http://wiki.apache.org/hadoop/HowToContribute. > > > DETAILS > > I finished a change for > https://issues.apache.org/jira/browse/HADOOP-7359, developed in a > branch on my github fork. Generating a diff between my branch and > trunk is straightforward, however, generating patches per-project > would require reworking the patch into 3 branches. Also, since the > patch changes something in common that's used in both HDFS & MR > submitting as separate patches will certainly break trunk for a brief > period. > > With the merged repo, submitting patches that span projects via a > single diff is possible and potentially preferred. If > one-patch-per-project is still preferred I'll certainly do that, but > submitting a single patch is both easier from a development > perspective, won't cause temporary build breakage, and provides a > cleaner revision history. > > Thoughts? > > --travis > -- Todd Lipcon Software Engineer, Cloudera
