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

[Thiago Macieira]

Em Monday 05 November 2007 16:42:37 Johannes Sixt escreveu:
> Thiago Macieira schrieb:
> > After realising that we don't have to keep the history of the
> > supermodules, I came up with a different idea. Here's it:
>
> Of course, you need to track the history of supermodules. How else would
> you handle atomic cross-module commits?

See my other email. I expressed myself wrong.

> > 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
> >   [...]
>
> If there are two parallel structures, release/ and devel/, then you cannot
> get away with a single distribution point for the supermodules. At the
> least, release/KDE.git is needed. [And, technically, that's the only module
> that needs a tag like KDE_4_2, because that commit implies the commits in
> the submodules.]

Yes, releases/KDE.git still exists. The releases/ tree is unchanged from the 
previous proposal.

And releases/KDE.git is not the same repository as meta/KDE.git (or 
stable/KDE.git in the old proposal). Note the existence of kde-l10n.git 
inside it, for instance. The releases repository is just for the tagging.

> But then you also needed stable/KDE.git. Think of a cross-module change:
>
> * I change some API in kdelibs.
> * Then I need to update kdebase, etc.
> * In order to make the change atomic, I must make a commit in KDE.git that
> includes *my* new states of kdelibs, kdebase, etc.
> * I must make this commit available to others, else they see
> inconsistencies. 
> * Where do I do that? stable/KDE.git is the only 
> reasonable place.

Yep, but this is meta/KDE.git in this proposal. I.e., all developers must have 
push access to all the meta repositories.

> > 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.
>
> You are of course right here.
>
> I still suggest to reflect the (logical) module hierarchy also in the
> (physical) server layout. Simplicity is my only argument, though ;)

That's my original proposal, but I felt it had a drawback when repositories 
get renamed or moved. Now I don't think that's an issue because the 
supermodule repositories' old commits don't have to be updated.

So my currently preferred proposal is a mix of the two: the first one, plus:
- the kdereview and the playground/*.git repositories are supermodules 
  WITHOUT directories associated. They refer to repositories in projects/ or 
  outside the KDE servers.

-- 
  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/1791edf4/attachment.pgp