[Kde-scm-interest] Gitorious for KDE

[Thiago Macieira]

On Monday 05 May 2008 09:07:50 Johannes Sixt wrote:
> Patrick Aljord schrieb:
> > Hi all,
> >
> > I've posted on techbase a proposition for using Gitorious with KDE. We
> > have a few questions and suggestions there so please feel free to
> > answer us and help us with your ideas. We're very open. This is based
> > on the work of Mario Danic modified and adapted by David and Jorge
> > Cuadrado and myself.
> >
> > http://techbase.kde.org/index.php?title=Contribute/GitoriousKDE
>
> I've no comment on the Gitorious part. But IMHO the repository structure
> you propose is much too fine-grained (too many sub-modules). For a related
> discussion see the archive of this list, around 2007-11-01 and 2007-11-05.

I agree with Johannes here. I know Oswald wants the split at the library/app 
level inside the KDE main modules. But I don't think Git-submodule support is 
good enough for that purpose (I don't think it will ever be, since it's not 
the objective). That is, it doesn't feel like a single, unique repository.

Definitely not for kdelibs, kdepimlibs, kdebase, kdepim, which are very 
tightly-integrated modules. (In fact, given the current level of 
cross-repository copy/move support in Git, I'd be tempted to lump kdelibs and 
kdebase together) Some of the others may work, though.

One other thing I don't like is placing the forks inside the same level. I can 
see that on repo.or.cz and it doesn't look intuitive to me...

I would recommend doing that for the extragear/review/playground level 
modules, because those tend to share a lot less code. Each app and each 
library should get its own repository.

===

As for the types of users, I'd recommend a two-level approach: admins and 
developers. Admin is a select group of trusted people who have admin access 
to the server. Developer is anyone who has an account on the server.

Developer rights:
 - create "project" or "private" repositories, either as clones or new repos
 - submit to any mainline repository

Admin rights:
 - well, anything on the server :-)

The KDE servers do not allow anonymous Internet users to create their own 
repositories. They can use many Git hosting sites out there to do it. Or they 
can apply for a developer account.

Access levels to the bugtracking system are off-topic. We haven't started 
discussing that yet, but yeah, we'll need changes in the future.

Requesting a change in the structure can be done by anyone. What matters is 
consensus on the appropriate mailing lists. Admins just get the "please do 
it, everyone agrees" email. I also understand the differences between types 
of repositories:

 - all repositories are readable (clone, fetch)
 - "private" repositories are only push-accessible by its owner
 - "project" repositories have ACLs that can be controlled by whoever created 
	that project
 - "mainline" repositories are push-accessible by anyone with an account
 - "release" repositories are locked and are writable by the "release dude"
	Admins do manual control on these.

-- 
  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/20080505/42f419d0/attachment.pgp