< Projects Revision as of 21:49, 8 September 2010 (view source)Toma (talk | contribs) (→Definitions)← Older edit Revision as of 21:51, 8 September 2010 (view source) Toma (talk | contribs) (→Reviewboard)Newer edit → 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 comments: comments: Revision as of 21:51, 8 September 2010 Contents 1 Definitions 2 Comparison 2.1 svn2git 2.2 Reviewboard 2.3 Redmine 2.4 gitolite 2.5 git 2.6 user workflow 2.7 releases 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 assign a dedicated review group per app 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: Retrieved from "https://techbase.kde.org/index.php?title=Projects/MoveToGit/Layout&oldid=54198" Content is available under Creative Commons License SA 4.0 unless otherwise noted.