[Kde-scm-interest] On Amarok Switching to Git

[Thiago Macieira]

Ian Monroe wrote:
>> SVN externs are not a problem. They just die. Get rid of them right
>> now, on SVN (they are hurting you now because you're using git-svn).
>> SVN and Git users will thank you.
>
>Actually we already got rid of them. I was confused. :)
>
>Still we need to have this info recorded somewhere. I suppose having
>it in a deep freezed SVN server somewhere is good enough.

Thanks! That made me happy! :-)

Amarok was the worst to maintain via git-svn.

>>  * how to create personal or group repositories. Should we use
>> Gitorious or GitHub?
>
>We don't have to decide this. People can do what they want. Some
>standard solution is a good idea though.

You're missing the point.

Suppose we have the Amarok repository. Good.

Now imagine you have 10 different branches on your local computer of 
Amarok, for crazy stuff you're doing. Wouldn't you want to share some of 
them? Wouldn't you want to back them up?

That requires setting up a personal repository for you. And for anyone 
(who?) who may want one too.

Also imagine that a subset of the amarok devels want to work on a crazy 
new feature together. They should have a repository for sharing their 
work. It could be the central, main repository, but I would argue that 
that repository should be kept clean, with one or two branches at most 
(easier for cloning, less data to transfer). So those developers should 
create a new repository for them.

Our experience with Gitorious (and of extending it) inside Qt Software is 
quite pleasant. Anyone with an account can create a server-side clone of 
any project. And everyone with accounts are given automatic push-rights.

We split our repositories in three sub-categories (per project):
 - baseline
 - shared
 - personal

Baseline repositories have only one branch and you cannot create more, 
delete it or force-push into it.

A shared repository has branches without slashes which behave like 
baselines, but anyone can create a new one (you can't delete them though). 
But if you push to yourusername/branchname, you're allowed to delete 
branches and rewrite history.

Finally, in personal repositories, anything goes. I keep all my branches 
in qt/tmacieirs-qt.git, to which I push with --mirror.

These restrictions are not meant as access control. Instead, they are 
meant to prevent mistakes.

Deleting repositories is also supported.

[All of this is obviously not specific for Gitorious; other solutions can 
do the same. It just happens that we have already modified Gitorious 
sources]

>>  * the unresolved issue of accountability
>
>This is the main issue I see. I hear there are solutions though?

We have to see whether Git notes solves the problem.

>>  * who will have push rights? To which branches? Who can create
>> branches? Which branches/repos will allow force-pushes?
>
>Well everyone will have push rights. I don't know what a force push is.

Force-push is a push with the -f flag, which makes the server accept 
changing the branch to a commit which is not a descendant of the current 
branch tip.

This can be controlled with server-side hooks, like I described above. We 
can share the ones we have for Qt Software.

>>  * SSH accounts for the Git server
>>    (every single KDE contributor using HTTPS must mail an SSH key)
>
>s/everyone/everyone who wants to develop Amarok/

True. But those who already have SSH accounts (svn+ssh) can be added 
directly.

Note that SSH will be mandatory for everyone.

>>  * the general layout of the server hierarchy (Amarok may be the
>> first, but we hope it's not the last, so we need some future-proofing)
>
>I don't understand why? The Amarok git repo can move around in future.

Sure, it can, but if it does, everyone tracking it needs to change their 
URLs.

In any case, after having experience with Gitorious, I would simply 
recommend the following layout:

git.kde.org:amarok/mainline.git
git.kde.org:amarok/amarok-21.git   [Gitorious doesn't support dots]
git.kde.org:amarok/amarok-20.git
git.kde.org:amarok/eeans-amarok.git
git.kde.org:amarok/markeys-crazy-hacks.git
git.kde.org:amarok/magnatune-rewrite.git

git.kde.org:kdelibs/mainline.git
git.kde.org:kdelibs/kde-42.git
git.kde.org:kdelibs/kde-41.git
[+ personal/shared repos]
git.kde.org:kdebase/mainline.git
git.kde.org:kdebase/kde-42.git
git.kde.org:kdebase/kde-41.git
[+ personal/shared repos]

git.kde.org:research/newapp1.git
git.kde.org:research/newapp2.git
git.kde.org:research/newlib3.git
[this is the kitchen sink, new apps and research ideas should start here]

git.kde.org:meta/KDE-trunk.git
git.kde.org:meta/KDE-42.git
git.kde.org:meta/kdesupport.git
git.kde.org:meta/kdesupport-for-42.git
git.kde.org:meta/extragear-full.git
git.kde.org:meta/extragear-multimedia.git
git.kde.org:meta/extragear-base.git
git.kde.org:meta/kdereview.git
git.kde.org:meta/playground-full.git
[etc., see below]

>>  * should we use supermodule/supermodule? Should we use repo?
>
>Again we don't need to decide this. (assuming I understand what you're
> saying).

This is about the last chunk above. Git submodule would work for what I 
described above. I am not sure about repo.

It's not necessary for getting Amarok going, but would be nice if we could 
present it as part of our plan.

>>  * should we use a patch-submission-and-review system? (probably not)
>
>no.

Thought so too. But we're going to use it for Qt, to make sure we don't 
break our tests when submitting.

-- 
  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/20090118/74ea81c1/attachment.sig