Seems like we just do a subtree merge into the ceph.git and call it good. -Sam On Wed, Apr 13, 2016 at 12:00 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > On Wed, 13 Apr 2016, Gregory Farnum wrote: >> On Wed, Apr 13, 2016 at 11:38 AM, Sage Weil <sweil@xxxxxxxxxx> wrote: >> > On Wed, 13 Apr 2016, Samuel Just wrote: >> >> It also doesn't seem like it would actually present a problem in any case. >> > >> > The reason we didn't do this before was because we wanted to revise tests >> > independently of the thing being tested. But as John points out, >> > specifying a test branch should accomplish that, at least for testing. >> > >> > It might be nice to preserve the ability specify an alternate repo with >> > totally out-of-tree tests. Maybe that can be done with a simple reorg of >> > the repo, like putting everything under qa/, so that tasks/ and suites/ >> > don't appear at the top level (of ceph.git or ceph-qa-suite.git). >> >> I shudder to suggest it, but would we get what we're really after by >> including a ceph-qa-suite submodule in ceph.git, and having the >> teuthology scheduling refer to that? Then we can update ceph-qa-suite >> independently while still having an atomic switch for the tests that >> goes into the same Ceph branch which makes the changes requiring them. > > Not really. The workflow for updating submodules is really painful. > Something like > > - commit to sub.git > - push to branch in public sub.git > - commit to main.git updating submodule sha > - push to branch in main.git > ... > - merge main.git branch > - merge sub.git branch (if you remember) > > ...and there are no "merge" semantics if there are racing sub.git updates. > > Submodules only really work for things that are infrequently updated... > > sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
