[Kde-scm-interest] Layout of the Git repositories for KDE (proposal #2)

[Thiago Macieira]

After realising that we don't have to keep the history of the supermodules, I 
came up with a different idea. Here's it:

projects/, users/, unmaintaned/, other/, releases/
  unchanged from the previous proposal

stable/
  kdelibs.git
  kdepimlibs.git
  kdebase.git
  [...]
  strigi.git
  koffice.git
  amarok.git
  qca.git
  konversation.git
  qt-copy.git
  [...]

l10n/  [could also be nested inside stable/]
  af.git
  ar.git
  be.git
  [..]

meta/
  all.git  -- matches subversion's trunk
  kdesupport.git
  KDE.git
  kdereview.git
  extragear.git
  extragear-libs.git
  extragear-base.git
  extragear-multimedia.git
  extragear-network.git
  playground-libs.git
  playground-base.git
  playground-nonkde.git
  [...]

The idea here is that stable/ is a *flat* tree with repositories. It can be a 
list as long as http://git.kernel.org. It doesn't really matter. Technically, 
the same layout of stable/ could be applied to releases/.

The important thing is that the organisation of KDE is reflected in the meta 
repositories -- i.e, the supermodules. We'd expect people to check out the 
meta repositories if they're interested in building KDE in general. If they 
are contributors to one or just a few modules, they can check out what they 
want exactly.

However, our replacement for websvn shouldn't be a gitweb with the entire list 
of repositories, like git.kernel.org. That's unreadable. We should present 
the user the all.git repository and then follow submodule links.

Advantages of this model are:
 - all.git can link into both stable/ and meta/:
    submodule "KDE" points to meta/KDE.git
    submodule "koffice" or "qt-copy" points to stable/$1.git
 - in fact, we don't *necessarily* need any of the other submodules. They're 
   there only to avoid imposing the tree on everyone.
 - an application progressing from playground, through kdereview, to 
   extragear, needs only a simple adjustment in the source and target meta 
   repositories.
 - no one said that submodule links have to point to the KDE server: we can 
   have an application for review in kdereview being hosted somewhere else, 
   which will be imported only when it's passed the review stage.
 - by the same token, the submodule link in kdereview can be pointing to 
   projects/, in the case of a new application.

Taking the case of a module that got dropped (kdetoys):
 - it existed as stable/kdetoys.git
 - meta/KDE.git pointed to it
 - it got released, so a new repository was created in releases/KDE/kdetoys
 - it got dropped:
   * all of its content was imported somewhere else
     unmaintained applications went to unmaintained/appname.git
     maintained applications went to stable/appname.git and a link was set up 
     from the proper meta/extragear-*.git repository
   * any alternate links were removed
   * meta/KDE.git's submodule link was removed
   * stable/kdetoys.git was removed
 - when the next release of KDE is tagged, the releases/KDE.git supermodule 
   will not contain the submodule link
 - but releases/KDE/kdetoys.git will exist ad eternam

Taking the case of an application (app) that got dropped but existed in 
extragear/foo:
 - it existed as part of stable/app.git
 - meta/extragear-foo.git pointed to it
 - it got released, so a new repository was created in releases/app.git
 - it got dropped:
   * the link in meta/extragear-foo.git was removed
   * the repository stable/app.git is moved to unmaintained/app.git
 - but releases/app.git will exist ad eternam

Taking the case of an application (app) that got dropped from a KDE module 
(kdemodule):
 - it existed as part of stable/kdemodule.git
 - it was released, as part of releases/KDE/kdemodule.git
 - it got dropped:
   * its content was copied (with history) to unmaintained/app.git [1]
   * its directory in stable/kdemodule.git was removed
 - the next release KDE will no longer contain the subdirectory

Note 1: if it were possible to have a submodule link to a subdirectory (i.e., 
partial checkout), all you would need is a single file in 
unmaintained/app.git. No need to duplicate the objects.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20071105/88fb45e3/attachment-0001.pgp