Projects/GitoriousKDE

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

2) If there are submodules admins, who does grant them there role? the supermodule admin?

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

4) is it necesary to implement "applying for developer status" or will it continue to happen by mail as it does now?

Answers to these questions we have so far

According to Mario Ðanić:

• first question: any commiter to mainline can grant access. It is assumed that developers will discuss that between themselves anyway.
• If there are submodules admins, who does grant them there role? the supermodule admin? --> Submodules admins are just commiters to mainline of the submodule.
• Gitorious would be a websvn replacement only, and not a bugzilla replacement
• it is neccessary to implement applying for developer status

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

kdelibs.git

 ...
 playground/
   project1.git
   project2.git
   ...

kdebase.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?

5) Automatically generate 4.1_Feature_Plan Feature Plans, when a branch is created its status is marked as "TODO", when it starts get some commits, its status is marked as "IN PROGRESS", when the branch is merged back in mainline its status is marked as "DONE".

Sum up of the evaluation

What needs to be done

• adapt Gitorious to include roles for project members. Those would be developers and admins. For now, gitorious has the concept of "committers" who can commit to mainline (or a clone), those would be KDE developers.

• it is necessary to implement the concept and managment of supermodules in Gitorious (those supermodules would be KDE super projects such as kdelibs, kdebase, kdeedu...). This functionality is already on the TODO list of Gitorious.

• the visibility of a project's clone will be modifiable by its creator, ability that only developers will have

• migration scripts to migrate bugzilla db to gitorious (suggestion)

• adapt gitorious design to KDE web style

• Annex: create plasmoids that will make use of the Gitorious web service api.