Projects/MoveToGit/Layout: Difference between revisions
< Projects
m (→Definitions) |
m (formatting) |
||
| Line 18: | Line 18: | ||
===svn2git=== | ===svn2git=== | ||
modules: | modules: | ||
*some work has already been done on creating module repos | |||
*moves within modules can be ignored | |||
split: | split: | ||
| Line 25: | Line 25: | ||
===Reviewboard=== | ===Reviewboard=== | ||
modules: | modules: | ||
*less projects to choose from when submitting a patch? [web only, not an issue with post-review] | |||
*no namespacing issue | |||
split: | split: | ||
*if something moves to another module, no changes are needed | |||
comments: | comments: | ||
*the reviewer groups won't be affected | |||
===Redmine=== | ===Redmine=== | ||
modules: | modules: | ||
*no namespacing issue | |||
split: | split: | ||
*source code links are automatically available on each applicaton page, instead of the module page | |||
===gitolite=== | ===gitolite=== | ||
modules: | modules: | ||
*no namespacing issue | |||
split: | split: | ||
*easier to find projects | |||
===git=== | ===git=== | ||
modules: | modules: | ||
*projects can keep their interdependencies, module-wide libraries and so on | |||
*less server space | |||
split: | split: | ||
*moving a project (eg. to unmaintained) moves its whole history | |||
===user workflow=== | ===user workflow=== | ||
modules: | 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: | 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: | 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=== | ===releases=== | ||
modules: | modules: | ||
*closer to what we have with svn?? | |||
split: | split: | ||
Revision as of 20:52, 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: