Projects/MoveToGit/Layout: Difference between revisions
< Projects
(→Reviewboard: clarification) |
|||
Line 30: | Line 30: | ||
split: | split: | ||
*if something moves to another module, no changes are needed | *if something moves to another module, no changes are needed | ||
*ability to assign a dedicated review group per app | *ability to auto-assign a dedicated review group per app, instead of per module | ||
comments: | comments: |
Revision as of 23:06, 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 stay the same as it is now
split:
- each SC application is one repository.
- kdelibs and pimlibs are one repo each. kdebase can be split on workspace/runtime/apps, where optionally apps could be split further
- extragear and review/playground as above.
- tarballs stay the same as it is now
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
- ability to auto-assign a dedicated review group per app, instead of per module
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: