Projects/MoveToGit/Layout: Difference between revisions

From KDE TechBase
Line 48: Line 48:


split:
split:
*easier to find projects
*easier to find projects (git.kde.org/APPNAME.git instead of git.kde.org/SOMEMODULE/APPNAME.git)


===git===
===git===

Revision as of 20:23, 9 September 2010

Definitions

modules:

  • each SC module is one repository except kdepim, it will be split into kdepim and kdepim-runtime.
  • 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 kdepimlibs are one repo each kdepim will be split into kdepim and kdepim-runtime. 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:

  • existing rules can be used with minor changes for "self contained" applications

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 autocreate (and possibly assign) a 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.kde.org/APPNAME.git instead of git.kde.org/SOMEMODULE/APPNAME.git)

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: