[Kde-scm-interest] KDE Git hosting status update

[Eike Hein]

On 06/10/2010 03:18 PM, Ian Monroe wrote:
> 2010/6/9 Eike Hein <hein at kde.org>:
>> Hi,
>>
>> as all of you know, over the past several months the board of KDE
>> e.V., on behalf of the KDE community, has been in negotiations with
>> Shortcut AS to investigate the possibility of KDE hosting its full
>> set of planned Git repositories on Shortcut's Gitorious.org plat-
>> form. At the end of this process, it became clear that a mutually
>> acceptable agreement was not in the cards.
>>
>> The board informed the KDE Sysadmin team, of which I'm a member and
>> on behalf of which I'm writing to you now, of this likely outcome
>> in late May and asked us to start seriously looking into how we
>> would implement Git hosting in the context of our own infrastruc-
>> ture, which had always been on the table as an option as well.
>>
>> In response to the board's request, the Sysadmin team has performed
>> a series of test installations and evaluations of software stacks
>> and compiled a report detailling the solution we decided we should
>> run with. This report has been shared with the board and the mem-
>> bership of KDE e.V. earlier today and we're happy to say has so far
>> been met with very positive feedback.
>>
>> We're sharing it with you now - see the attachments to this mail -
>> and hope you will agree that we have found a solid way forward for
>> the KDE Git migration efforts.
>>
>> We look forward to your input, and will naturally keep you posted
>> as the situation develops further with regard to the production-
>> readyness of KDE's Git hosting facilities, and of course will have
>> to work together on future migrations both from svn.kde.org and of
>> the repositories we currently have on Gitorious.org.
> 
> Great report and thanks to the sysadmin team for making this happen.
> 
> How does ReviewBoard merge requests work with Git? At work there was a
> script that submitted patches to reviewboard from a git repo, so it
> was still very much patch-based. The problem with patches is that
> don't have the context saved of what they were patching aganist. It's
> kind of the whole point of Git branches.
> 
> But I haven't looked much at ReviewBoard+git, and certainly not its
> unreleased features. So I'm basically wondering if the basic workflow
> of Gitorious merge requests is preserved in ReviewBoard: work on issue
> in a private or feature branch, request that the branch get merged,
> make corrections based on suggestions in the review request, merge
> finished branch. If ReviewBoard can't review branches its not really
> functionally the same as Gitorious and serves quite a different
> purpose (though I can't disagree with the overall conclusion of the
> sysadmin team).

That's actually not quite how Gitorious merge requests work:
While the origin of a merge request is often a feature branch,
a merge request actually gets stored as refs in the repository
it is intended to be merged against, and if the feature branch
receives new commits, the merge request has to be manually up-
dated by the requestee. In effect you're not reviewing a branch
on Gitorious either, but a static diff, too, except it gives
the requestee a nice way to update the diff.

You can add the requestee's personal clone on Gitorious as a
new remote in your local clone and examine his feature branch
directly, however there is no guarantee the feature branch
contains the same as the merge request, since the two can di-
verge without the requestee updating the merge request.

As for ReviewBoard, ReviewBoard ships a command line utility
that can be used to create a merge request from changes in a
local clone. This command line utility is capable of auto-
discovering the URL of the ReviewBoard instance it is suppo-
sed to use from the configuration of the git repository it is
run against, which in turn comes from the repo it was cloned
from. In other words, on our server end we can configure the
repositories to contain the ReviewBoard URL, and then some-
one cloning the repository can comfortably use the Review-
Board command line utility to create and update review re-
quests, in a manner similar to how Gitorious merge requests
work. At that point, as a review tool, ReviewBoard is quite
a bit more capable than Gitorious' UI.

What we're not going to do, at least initially, is to allow
outside people to make an account with us and create perso-
nal clones of KDE repositories on our infrastructure. But
that is not a software question; it would have been the same
had we chosen to install Gitorious.

Note however that KDE developers are going to be able to
create personal clones.


> Ian

-- 
Best regards,
Eike Hein