[Kde-scm-interest] Alternate Git options

[Jeff Mitchell]

On 5/12/2010 9:50 AM, Ian Monroe wrote:
> 2010/5/11 Jeff Mitchell <mitchell at kde.org>:
> [snip]
>> At this point, if I had to pick a solution for us, I'd say Gitolite +
>> Redmine, with migration of our Bugzilla over to Redmine. I think this
>> provides a pretty nice capability, allowing each project to have its own
>> issues, wiki, news, repository, and so on yet still be a part of the KDE
>> whole. Clean separation, yet still unity. We could even still throw cgit
>> on top, allowing for multiple ways of browsing code depending on
>> individuals' preferences.
> 
> An important basic feature of Gitorious is the ability to create team
> and private repos on-the-fly without help from an administrator. Given
> how Git works, if KDE doesn't provide this itself we will find people
> using github and gitorious and we fail the "keep the community
> together" test.
> 
> I'm guessing it might be possible with Gitolite's more advanced ACL to
> do things like allow the creation and deletion of remote branches
> without allowing force pushes in the master branch (disabling force
> pushes in at least master is needed for revertabliity). These remote
> branches could perform the duty that clones and forks provide in
> gitorious and github. It would be a bit messy since remote branches
> are a flat list, but having multiple repos for the same project is
> also messy so its just a tradeoff.

Yes, you are quite correct in that this feature is indeed important.

If we were to use Gitolite I would hope that we could have an ability to
do this, even if we need to do some custom coding. It should not be too
hard, for instance, to have a button next to each repository on a web
view that allows a user to (after authenticating with OpenID or some
such thing to prevent attacks) generate a private clone that they can
work on, using some unique URL and an SSH key that they provide. We
could then "garbage collect" these if they have e.g. not been committed
to in 30 days.

KDE developers could by default have pull access to these repositories,
so even if there is no current "merge request" capability a quick and
dirty way (that could be improved later) might be to have a form where
the user can send information to the appropriate team with a
repository/branch and a range of commits and a reasoning.

IOW -- we may be able to relatively easily do 95% of what we need from
Gitorious, just with less flash and panache, hacking a custom plugin or
web forms onto cgit or redmine or retrovista and using gitolite as the
backend.

Over time, interested parties could even develop this further if they
wanted to e.g. generate something like GitHub's network view.

--Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20100512/7fba2efc/attachment.sig