Projects/MoveToGit/Layout: Difference between revisions
(initial documentation of modules vs split) |
m (→Definitions) |
||
Line 1: | Line 1: | ||
==Definitions== | ==Definitions== | ||
modules: | modules: | ||
*each SC module is one repository. | |||
*each extragear application is one repository. | |||
*kdereview and playground are implemented with individual repos and/or branches? | |||
*tarballs?? | |||
split: | split: | ||
*each SC application is one repository. | |||
*kdelibs and pimlibs are one repo each. kdebase is split how? | |||
*extragear and review/playground as above. | |||
*tarballs?? | |||
==Comparison== | ==Comparison== |
Revision as of 20:50, 8 September 2010
Definitions
modules:
- each SC module is one repository.
- each extragear application is one repository.
- kdereview and playground are implemented with individual repos and/or branches?
- tarballs??
split:
- each SC application is one repository.
- kdelibs and pimlibs are one repo each. kdebase is split how?
- extragear and review/playground as above.
- tarballs??
Comparison
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.
svn2git
modules: -some work has already been done on creating module repos -moves within modules can be ignored
split:
Reviewboard
modules: -less projects to choose from when submitting a patch? [web only, not an issue with post-review] -no namespacing issue
split: -if something moves to another module, no changes are needed
comments: -the reviewer groups won't be affected
Redmine
modules: -no namespacing issue
split: -source code links are automatically available on each applicaton page, instead of the module page
gitolite
modules: -no namespacing issue
split: -easier to find projects
git
modules: -projects can keep their interdependencies, module-wide libraries and so on -less server space
split: -moving a project (eg. to unmaintained) moves its whole history
user workflow
modules: -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
split: -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]
comments: -kdesrc-build, build-tool and mr make it easy to handle large numbers of repos, although there's still room for improvement on userfriendliness.
releases
modules: -closer to what we have with svn??
split: