[RFC] SVN Guidelines.

[Tom Albers]

Hi All,

We already talked about the lifecycle of  KDE applications a couple of times. I felt it was time to fit it in some kind of document so new developers can get a quick overview of where the application should go. Below is a draft of such a document. 

I also added a diagram which can be added to the page. One change is that I would like to suggest is to get ourselves a coordinator, he would be a primary contact regarding questions about this.

Another change is that unmaintained applications should move the /tags/unmaintained (name is up for suggestions). Where unmaintained is defined as one year without commits. The coordinator can then contact the listed maintainer and ask for the intentions as described below, this will keep playground and review a workable place imho. 

I hope this reflects what we discussed earlier on this list and you like the enhancements I suggest.

Toma

-----

This page describes the life cycle of an application and the corresponding place in KDE's repository.

First stage: the start.
The start of a new application can take place on a local disk, in a local repository or any other way. Another option is provided by KDE in the special /trunk/playground folder in the repository where everyone is free to commit his own application. You can request a SVN account at sysadmin and after that you can import your project in the subfolder of your choice.

It is not meant as a backup area, so you should not develop your application somewhere else and only sync the changes now and then to KDE's repository.

As soon as you start releasing your software and match the criteria for the next stage, you should consider moving your application folder to the next stage. 

Because playground is something like an 'experimental' area, there is only a small amount of applications that make it to the next stage. To keep the playground area accessible and a bit organized, we have created a /tag/unmaintained[3|4] (/tags/unmaintained3 for KDE3 and /tags/unmaintained4 for KDE4 based applications). If you do not want to continue your application, move it to that place in the repository. If you do not know how, contact the current contactperson which is mentioned at the bottom of this document.

Whenever an application has not received a commit for one complete year, you will be contacted via email to discuss if you want to continue the application or if it has died. In the latter case or when the email bounces, it will be moved to /tag/unmaintained[3|4].

This also applies to the currently no longer used /trunk/kdenonbeta area.

Second stage: stable.
When you have made a couple of releases, the term 'playground' does no longer apply to you. That is the right time to move out of here. There are two options to move to: extragear and one of the KDE main modules. If you want to move to one of the KDE main modules, you will get released with KDE. That also means you have to respect that release schedule. In extragear you are on your own. You make the releases whenever you want and you have to talk to the translators about your release schedule.

Whatever you choose, there are some rules to follow before you are allowed to move to either location: 
- there should be user documentation in the form a docbook
- there should be developers documentation in the form of apidox
  you can check this at ebn[1]
- there should be no krazy issues reported, 
  again, you can check that at ebn[1]
- if possible, there should have been a basic usability review of your application. Usability people are hard to get, so this is not crucial.
- you should have checked for basic problems with a profiler. I hope we will get a tutorial on how to do this soon. 

When you decide you want to move to this second stage, you move your application to /trunk/kdereview. Then you sent an announcement to kde-core-devel at kde.org that you have done that, address above issues and make clear where you want to move to (which kde main module or extragear).

Then the two weeks review period starts. In those two weeks people can object to your proposal, request additional changes or scream at you in general. When there are no objections after the two week period, you are allowed to move your application to the place you decided to go. 

If there are changes requested and they are small, you can make them while in kdereview, after that change, announce it again to kde-core-devel and wait for one week for objections. If there are big changes requested, then you need to move back to the playground module. After that you can move it back to review and the process starts from the beginning.

In no case kdereview can be a permanent place to develop your application. At the time of writing this document, there are some applications in kdereview, they will be contacted to see what is the best way to proceed.

Third stage: the end.
Whenever you decide to stop developing the application and that leaves the application without developers, please announce that to kde-core-devel. When nobody stands up to take over maintainership within two weeks, the application has to be moved to the /trunk/unmaintained[3|4] area as every application in the KDE main modules and in extragear needs to have a maintainer to stay there.

-------------

Things to decide:
- translations, is sysadmin able to do the move them around or should that be the task of the forementioned coordinator.
- the coordinator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdeflow.png
Type: image/png
Size: 18233 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070227/1c89035a/attachment.png>