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
