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

[Thiago Macieira]

Em Monday 05 November 2007 17:32:45 Oswald Buddenhagen escreveu:
> On Mon, Nov 05, 2007 at 05:00:43PM +0200, Thiago Macieira wrote:
> > After realising that we don't have to keep the history of the
> > supermodules, I came up with a different idea. Here's it:
>
> now you're coming closer to what i imagined - i.e., something sane. ;-P

:-)

> there are a few key points to consider:
> - *no* repository ever gets moved or deleted once it was created.
>   anything else is just not going to work, both for current work
>   with the repos and for reproducing old revisions.

Where does it break down in the examples I posted?

I don't like the idea of keeping repositories in "trunk" 4 years after the 
last commit has been made to it. I do find that moving to unmaintained works 
best, because it doesn't clutter trunk.

> - that basically mandates that everything lives in one directory. to
>   avoid having 1000+ objects in one directory one could group the
>   repositories by application category, but *not* by maturity,
>   supermodule membership, etc.

Makes sense, agreed.

But the moment that you start to categorise, you open the door to 
re-categorisation too. That is, when a new category is added (say, "plasma"), 
some things will want to move because they match better (than, say, "base").

> - higher structure is represented exclusively by supermodules (three
>   level hierarchy - e.g, kdebase, KDE, everything. some apps might even
>   opt for a fourth private level to combine several components).
>   this makes it obvious why a fine granularity is crucial.

I don't agree with kdebase being a supermodule. I don't know if that's what 
you meant.

But I agree to the three-level hierarchy:
1) all.git supermodule, containing links to:
2) KDE.git, kdesupport.git, extragear-libs.git, playground-multimedia.git, 
etc., which links to:
3) module, application or library (kdebase.git, amarok.git, qca.git, etc.)

Note that there are exceptions to the rule: qt-copy & koffice, which are 
linked from all.git directly.

> the overall structure oriented on your proposal would be like this:
>
> trunk/ (or main/ or master/ or official/ - "stable/" seems just wrong to
>   me)

It's a marketing trick to get more people to use it :-)

> releases/ (one could call *that* stable/, but that's less descriptive)
> other/ - maybe. i don't see much advantage over putting it in trunk/,
>   though.

I isolated "other" because I don't know how those fit into the structure. More 
importantly, they don't get linked from all.git.

> projects/ - here one could relax the "never deleted" rule, assuming
>   everything here lives inherently outside of official strutures.
>   every project that wants to branch more than one module creates its
>   own clones of supermodules, obviously.

Yeah.

> users/ - maybe. but why would somebody put something here instead of
>   under projects/?

Personal back-up and personal projects.

If you're working on something on your own because you had a crazy idea, you 
push it there. If you want other people to review your patch before you 
commit, you push it there.

If you're not part of the team of a project, you should refrain from 
committing to their repository. So just clone it and send them a link to 
where to pull.

Another possibility is to store your own webpages or presentations.

The big difference to projects is that projects has a time limit, whereas user 
repositories could live forever.

> "blackhole/" does not exist by definition. it would be a supermodule in
> trunk/.

Don't agree, see above.

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