Goal

Improve and adapt the Gitorious Web Application for its use in the development of KDE

Process and development of the project

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.

KDE repository structure

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:

Supermodules

kdelibs.git

 README/TODO/CMake/...
 includes
 doc
 ...
 kdecore.git    (module)
 kdeui.git      (module)
 kio.git        (module)
 knewstuff.git  (module)
 ...

kdebase.git

 README/TODO/CMake/...
 includes
 doc
 ...
 plasma.git     (module)
   ruphy-plasma.git
   notmart-plasma.git
   chani-plasma.git
   someone-plasma.git
   ...
 kdm.git        (module)
 ...

KDE commit politic

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).

Type of users and their abilities

regular users

ability to create clones and commit to their clones
ability to make merge request to mainline
ability to apply for developer status
ability to request for the creation of a new supermodule/submodule
ability to make bug reports/whishes

KDE developers

ability to make commits to mainline
ability to accept or reject appliances for developer status (see question 2)
ability to request for the creation of a new supermodule/submodule

Administrator

ability to create (and remove?) supermodules and submodule
ability to move submodule from one supermodule to another supermodule (ex: kdeplayground=>kdeedu )
ability to accept creation of new projects inside of supermodules

This is what we have so far.

We have a few questions too

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?

Suggestions

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):