Difference between revisions of "Projects/MoveToGit/Layout"

Jump to: navigation, search
m (Definitions)
m (formatting)
Line 18: Line 18:
 
===svn2git===
 
===svn2git===
 
modules:
 
modules:
-some work has already been done on creating module repos
+
*some work has already been done on creating module repos
-moves within modules can be ignored
+
*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]
+
*less projects to choose from when submitting a patch? [web only, not an issue with post-review]
-no namespacing issue
+
*no namespacing issue
  
 
split:
 
split:
-if something moves to another module, no changes are needed
+
*if something moves to another module, no changes are needed
  
 
comments:
 
comments:
-the reviewer groups won't be affected
+
*the reviewer groups won't be affected
  
 
===Redmine===
 
===Redmine===
 
modules:
 
modules:
-no namespacing issue
+
*no namespacing issue
  
 
split:
 
split:
-source code links are automatically available on each applicaton page, instead of the module page
+
*source code links are automatically available on each applicaton page, instead of the module page
  
 
===gitolite===
 
===gitolite===
 
modules:
 
modules:
-no namespacing issue
+
*no namespacing issue
  
 
split:
 
split:
-easier to find projects
+
*easier to find projects
  
 
===git===
 
===git===
 
modules:
 
modules:
-projects can keep their interdependencies, module-wide libraries and so on
+
*projects can keep their interdependencies, module-wide libraries and so on
-less server space
+
*less server space
  
 
split:
 
split:
-moving a project (eg. to unmaintained) moves its whole history
+
*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
+
*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)
+
*increases passive testing of trunk (more people to notice if the build's broken)
-lower barrier to hacking on other projects in the module
+
*lower barrier to hacking on other projects in the module
-easier to refactor a module [rare]
+
*easier to refactor a module [rare]
-less downloading & disk space for those who want entire modules
+
*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
+
*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 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]
+
*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.
+
*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??
+
*closer to what we have with svn??
  
 
split:
 
split:

Revision as of 21:52, 8 September 2010

Contents

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:


KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal