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

The goal is to have a git repository for each KDE module, (Thiago: "given the current level of cross-repository copy/move support in Git, I'd be tempted to lump kdelibs and kdebase together"). Only playground would make use of submodules.

This is what it looks like:

Supermodules

kdelibs.git

 README/TODO/CMake/...
 includes
 doc
 kdecore/
 kdeui/
 kio/
 knewstuff/

kdebase.git

 README/TODO/CMake/...
 includes
 doc
 ...
 plasma/
 kdm/
 ...

• all repositories are readable (clone, fetch)
• "private" repositories are only push-accessible by its owner
• "project" repositories have ACLs that can be controlled by whoever created

      that project

• "mainline" repositories are push-accessible by anyone with an account
• "release" repositories are locked and are writable by the "release dude"

      Admins do manual control on these.

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

Developer rights

• create "project" or "private" repositories, either as clones or new repos
• submit to any mainline repository

Admin rights

• anything on the server

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

ruphy thinks that... 1) Several admins, for sure... but... do we really need that? I'd say that anyone should be able to send the occasional bugfix upstream. (at least in a mob-branch-fashon way?). However, this could be avoided if we make forking extremely trivial (as in pusing a button and waiting <5sec), and similarly also pull requests. 2) I really think so.... 3) I know bugzilla sucks, but we're going to stick with it for a while still... handling bugs for KDE is just extremely complicated. :\ 4) I... guess so? however, the simpler it is, the better.

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 Feature Plans by mapping branches to feature, when a branch is created its status is marked as "TODO", when it starts getting 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

initial IRC conversation

trapni:  thiago: I was looking for a git hosting service as my local host can't be up as good as a server, so I had to push the repo (including history, ideally) to such a service (I decided to use gitorious - hopefully it's good though :)
thiago:  ok
trapni:  thiago: finally, is kde moving from svn to git anytime soon? do you have an idea? (just to be curious)
thiago:  hasn't had the time to do that
thiago:  which means it hasn't moved, since I am the only person trying to do it
trapni:  i know tha lag of time, yep
trapni:  what are the issues?
trapni:  are there some?
thiago:  submodule support isn't good enough, we haven't finished writing the import rules, we don't know the layout of the repositories yet, we need some server software (web service) for creating and cloning repositories, setting ACLs; getting rid of svn:externals
trapni:  might be interesting to know wether there actually is an interest in moving from svn to git for the majority of kde devs or not
thiago:  ah, and support for copy-with-history
trapni:  ah, yeah
trapni:  one big lag of all those git hosting services is, that they don't provide a homepage for your project - to sad :)
pygi:  yet ;)
thiago:  we decided that all our repositories will have a mandatory wiki homepage
trapni:  a wiki is nice, yeah
thiago:  if you request a repo on the server, you have to write a wiki page saying what your repo is for
trapni:  on *what* server are you talking about?
trapni:  you mean the kde repository?
thiago:  git.kde.org
trapni:  oh, you really have one?
thiago:  no
trapni:  :(
pygi:  could volunteer during SoC to work with thiago to improve gitorious for kde needs ;)
trapni:  i also thought about having one of my libraries to be hosted at kde, in case you'd have a homepage *and* git for me (it's the capseo/libcaptury video capturing framework used by kwin) ;)
trapni:  pygi++
thiago:  I don't see why not
thiago:  we also need a central DNS registry for us because of D-Bus names
trapni:  yep
trapni:  thiago: what do you need me to do got get my git repositories (and wiki pages) hosted their?
trapni:  i'd be glad in fullfilling the requirements though :)
thiago:  1) get the server to exist
thiago:  2) get the software running on the server that doesn't exist yet
thiago:  3) get kde to convert
trapni:  aha, you mentioned the 'server' word - which i can't provide currently :D
thiago:  we have the machine already
trapni:  oh
pygi:  trapni, would be nice to have ability to request project addition, admins allow it, and then the space for website and git are provided for you
pygi:  (eventually even mailman auto-create magic even ;))
trapni:  pygi: exactly
thiago:  in half the cases, the new repositories are project branches
trapni:  while i noticed very very poor feedpack performance on savannah.[non]gnu.org where I first tried to host my capturing libraries on
pygi:  thiago, branches can be done without approval
thiago:  so the software should clone and set up the alternates link
trapni:  they do require admin acceptance, gitorious didn't - which i quited liked
pygi:  thiago, yup, one would be able to see a network of folks who cloned certain repos/branches
pygi:  only addition of new modules (repositories) would require admin approval
pygi:  cloned/forked branches dont need web-space, or mailing list, or anything, anyway
thiago:  pygi: right
thiago:  but we still want to enforce a wiki page describing the project
trapni:  forked branches maybe do, but general purpose branches don't (they're most likely to be merged back)
thiago:  so that we can have a proper list of repositories with their purpose
pygi:  thiago, well, yes ... wiki page per project, not per branch :)
thiago:  instead of a "braindump" like http://git.kernel.org/
thiago:  no, per *repository*
trapni:  thiago: i highly encourage the wiki-requirement, i guess nobody will have a problem with it, at least I were explicitely looking for a git hosting service with homepage feature (which I failed in finding yet anyways)
pygi:  thiago, yup
pygi:  trapni, that's what I meant, yes
thiago:  the idea of the wiki homepage is to describe what the repository is for, who's working on it, etc.
pygi:  yea, basic description of it and stuff
thiago:  exactly
thiago:  for separate projects (like trapni's idea), it might need some actual webspace and a domain name
thiago:  under the .kde.org hierarchy, so the project can have its own D-Bus namespace
pygi:  a lot of magic under :)
pygi:  so the "application" process would involve selection of services one needs, and a link to wikipage describing what the repository will be for, descriptions, and such
thiago:  yep
thiago:  the admin would also be able to select from the account list who's allowed to push there
pygi:  thiago, why not the repository owner?
thiago:  the admin = the repository owner
pygi:  ah, ok! I was thinking of complete system admin
thiago:  or anyone with push permissions. I don't see the need for making the distinction.
pygi:  aha, got it
trapni:  still admin != owner, their _maybe_ shall be a distinction, shouldn't it?
thiago:  I don't see the need
pygi:  ok, so no need for manual review process I take it
thiago:  whoever requests the repository is given push/admin rights over it
thiago:  and he can give those rights to anyone else
pygi:  thiago, nod, but who has the ability to approve the request?
pygi:  or is it approved magically?
thiago:  should be automatic for clones
pygi:  yea, but what for new repos? :p
thiago:  for brand-new projects, sysadmins
pygi:  yea, well .. that's what we're talking here =)
thiago:  you have to fit it into one of the supermodules anyways
trapni:  in my case, it's not a brand new project, I'm just looking for a sweet home :)
thiago:  you'd have to justify the relation to kde
thiago:  if it's in kdesupport, it's something kde uses
thiago:  if it's in extragear, it's kde-based
pygi:  ah, so one should be able to create project (say kdesupport) and then module under it!
thiago:  yeah, things have to be organised
pygi:  a lot of things to think about =)
trapni:  kdesupport is the relation
thiago:  my idea was to have a top-level hierarchy "stable" with kdesupport, kde, koffice and extragear supermodules
thiago:  then a top-level hierarchy "projects" with cloned repositories as well as new stuff (i.e., current playground)
thiago:  then a top-level hierarchy "users" for someone's own branches (no wiki page required)
thiago:  people don't get today in SVN the difference between /branches/work and /trunk/playground, so we might as well merge the concepts
pygi:  supermodules with projects under them
pygi:  joy :)

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