[RFC] SVN Guidelines.

Aaron J. Seigo aseigo at kde.org
Tue Feb 27 20:39:52 GMT 2007


On February 27, 2007, Tom Albers wrote:
> I hope this reflects what we discussed earlier on this list and you like
> the enhancements I suggest.

looks very good; thanks for doing this. i've added some comments below. do 
with them as you will .... =)


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

time to nuke this directory altogether?

> Second stage: stable.
> When you have made a couple of releases, the term 'playground' does no
> longer apply to you.

a couple of releases sounds a bit too long to me. even one release, even a 
beta release, should be enough?

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

perhaps a reference to a page noting what that means exactly would be cool.

> 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'd really, really like to see this changed, btw. e.g. i'd like to see an 
opt-in "release with KDE" option for extragear and have a release dude for 
extragear that would coordinate this. it would eliminate one of the reasons 
some people want so badly to be in main modules even if their app really 
doesn't fit the bill.

> Whatever you choose, there are some rules to follow before you are allowed
> to move to either location:

this might be a good time to update this:

	http://developer.kde.org/documentation/other/checklist.html

move it to techbase, and reference it from this document.

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

we should probably note that if the intention is to move to a main module then 
they must get approval from the maintainer(s) of that module. extragear only 
requires general approval on k-c-d, while going into, for instance, kdepim 
requires approval from the kdepim community who manage that module.

> or scream at you in general. 

oh, sure. warn them. half the fun is them not expecting it. ;) i'm kidding, of 
course; perhaps we should tone this down so as not to scare people. some 
people tend to take things a bit literally when they read them.

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

this shouldn't go into the actual document of course, right?

> 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

s,When,If, =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070227/c83891a6/attachment.sig>


More information about the kde-core-devel mailing list