- each SC module is one repository.
- each extragear application is one repository.
- kdereview and playground are implemented with individual repos and/or branches?
- each SC application is one repository.
- kdelibs and pimlibs are one repo each. kdebase is split how?
- extragear and review/playground as above.
Pros for each option (cons are rephrased as a pro for the other one)
Note: no mention of the magnitude of each point has been made yet.
- some work has already been done on creating module repos
- moves within modules can be ignored
- less projects to choose from when submitting a patch? [web only, not an issue with post-review]
- no namespacing issue
- if something moves to another module, no changes are needed
- the reviewer groups won't be affected
- source code links are automatically available on each applicaton page, instead of the module page
- projects can keep their interdependencies, module-wide libraries and so on
- less server space
- moving a project (eg. to unmaintained) moves its whole history
- keeps a sense of community by having a whole module kept together
- increases passive testing of trunk (more people to notice if the build's broken)
- lower barrier to hacking on other projects in the module
- easier to refactor a module [rare]
- less downloading & disk space for those who want entire modules
- less downloading & disk space for people who only want a small part of a module
- easier to get started on one little app?
- easier to avoid being exposed to unstable versions of other projects [I think that's a bit selfish though]
- kdesrc-build, build-tool and mr make it easy to handle large numbers of repos, although there's still room for improvement on userfriendliness.
- closer to what we have with svn??
Content is available under Creative Commons License SA 4.0
unless otherwise noted.