[RFC] SVN Guidelines.

[Albert Astals Cid]

A Dimarts 27 Febrer 2007, Tom Albers va escriure:
> 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.

Thanks for stepping up :-)

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

I think a clarification saying that "the fact you want your program in KDE 
main modules is not enough and others have to agree is valuable to have it".

>
> 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]

Imho asking for apidox is crazy for non libs.

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

I miss "- your program should be i18nable".

Albert

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