Improve and adapt the Gitorious Web Application for its use in the development of KDE
Evaluate the current peculiarities of Gitorious and the process or politics of the KDE development to define the new modifications needed to obtain the best integration with Gitorious.
First we need to study the KDE repository structure with Git. KDE is an umbrella of many big projects, each of them is made of several smaller parts that are projects of their own. What seems to be the current agreement is that KDE big projects would be git supermodules and KDE sub-projects would be git submodules.
This is what it looks like:
README/TODO/CMake/... includes doc ... kdecore.git (module) kdeui.git (module) kio.git (module) knewstuff.git (module) ...
README/TODO/CMake/... includes doc ... plasma.git (module) ruphy-plasma.git notmart-plasma.git chani-plasma.git someone-plasma.git ... kdm.git (module) ...
KDE has a history of being developer friendly and easily giving svn accounts to most people that apply for them. Git makes this even easier as anybody can commit to his/her own branch.
That being said, KDE is more or less a meritocracy and some developers have more power than others when it comes to administration. This is necessary but SVN can make the administration painful for admins and frustrating for wanna-be developers as they have to wait before they can commit.
Given that, we have thought of a simple user/role organization (no complicated rwx type of permissions system that nobody gets and uses).
This is what we have so far.
1) What's the use of private (ie non visible/redeable to others) clones?
2) The question is to know if each submodule of a supermodule will have one or several admin or if every developers of a submodule will have the ability to accept or reject new developers?
3) If there are submodules admins, who does grant them there role? the supermodule admin?
4) Gitorious would be a websvn replacement only or will it be a bugzilla replacement too? Gitorious devs are implementing ticket tracking as of this document writing.
5) is it necesary to implement "applying for developer status" or will it continue to happen by mail as it does now?
According to Mario Ðanić:
1) suggestion: anybody will be able to create projects/repositories/forks without any permissions, those projects will be moved to kdeplayground/<submodule> with the submodule created by the superadmin. The project creator could choose the submodule by him/herself. This seems to be in the spirit of kde playground, what do you think?
2) Playground module for each supermodule(kdelibs, kdebase):
... playground/ project1.git project2.git ...
... playground/ project3.git project4.git ...
playground/ (is a supermodule)
project5.git project.6git ...
3) knewstuff2 server (git repo => knewstuff2 => user )
4) If KDE is going to keep bugzilla, we can still hook up gitorious with bugzilla in order to make them work together. As an example when a commit message has "closes #123" it will close the bugzilla bug #123, that's just an example of interaction. To have this kind of interaction, we'd need bugzilla xml-rpc web service API turned on, is that the case?