Forgot to reply to this earlier. From the CouchDB side of things, even though we have many repositories, the combination of all those repositories will constitute a single source release. Our repository breakdown is mostly driven by how Erlang-the-language mandates a flat namespace coupled with Erlang-the-ecosystem which has developed tooling that expects individual repositories.
Paul On Sun, Sep 21, 2014 at 10:33 PM, David Nalley <[email protected]> wrote: > On Sun, Sep 21, 2014 at 12:26 PM, Reto Gmür <[email protected]> wrote: >> Hi Brian, David, all, >> >> Thanks for your feedback - and sorry for my late reply. >> >> I did some more playing around with the mvn:release plugins and >> unfortunately found no way to use it for individually versioned projects >> sharing a singe git repo. The maven git flow plugin also assumes one version >> per repository. >> >> Regarding the management of the repos: We do not plan to mandate the use of >> any tool. One of the advanatges of 1-repo per module is that people only >> need to check out and get into the subprojects they are actually interested >> in. Reactor projects will use git submodules to integrate the modules, so >> one can get all the modules by recursively updating the submodules of the >> root-reactor. >> >> In the case we want to draft a change that spans over multiple modules we >> would have to individually branch those projects and branch the reactor or >> provide a temporary reactor that contains only the branched projects. The >> temporary reactor approach is possible as the module depend on the released >> version of other modules by default, so the modules would depend on a >> SNAPSHOT version only where this is also branched. >> >> As for the release process: A goal of the new approach is to make releasing >> much easier ans thus much more frequent. So often we will be releasing just >> a single module. When releasing multiple modules we will generate several >> artifacts and call for a common vote. A single vote is necessary if the >> modules are interdependent, as otherwise the votes would have to be held >> sequentially following the dependency chain. >> >> Even if Infra is *very* responsive for 200 repos having a self-service >> system seems to be more convenient. Allura looks good, gitlab might be a bit >> easier as it is focused on git. >> > > I don't disagree that having a self-service system would be > convenient; it's come up in conversation several times in the past few > months. However, this isn't currently a priority for infra. For the > moment, projects have to keep their source code in an infra-maintained > repository. > > --David
