From kde-release-team  Tue Aug 19 21:58:29 2008
From: "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date: Tue, 19 Aug 2008 21:58:29 +0000
To: kde-release-team
Subject: Putting Playground in some order
Message-Id: <200808192358.29582.kossebau () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-release-team&m=121918302621235

Hi,

should we get some more structure into Playground? I fear it will otherwise 
end in the state kdenonbeta has been before if it isn't already: Lot's of 
started projects, but most of them dead code, making people uninterested in 
looking into it at all.

Take for example playground/utils:
http://websvn.kde.org/trunk/playground/utils/?sortby=date

There are currently 45 projects inside. 18 haven't seen any activity since 
seven month and more, only 8 have seen activity in the last four month 
besides scripty. There is also a mix of KDE 3 and KDE 4 dependencies.

So I would like to propose to have some little policy for playground:
a) Projects which have been without a commit for more than five month are 
moved to
	tags/unmaintained/playground/$submodule/{3,4}
if the authors/maintainers do not oppose within a month.
b) KDE3 based projects are moved to branches/playground/kde3/$submodule/ (cmp. 
branches/extragear/kde3/$submodule)

By keeping only active projects in playground third-parties like translators, 
dashboard maintainers or check drivers (cmp. *) do not spend their resources 
on dead things. And splitting of the KDE3 based ones should have been done 
long time ago.

* 
http://englishbreakfastnetwork.org/krazy2/index.php?component=playground&module=utils

Then the toplevel structure of trunk/playground does not exactly reflect the 
current KDE modules:
accessibility/
artwork/
base/
bindings/
devtools/
edu/
games/
graphics/
ioslaves/
multimedia/
network/
office/
pim/
sysadmin/
utils/

While trunk/KDE consists of:
kde-common/
kdeaccessibility/
kdeadmin/
kdeartwork/
kdebase/
kdebindings/
kdeedu/
kdegames/
kdegraphics/
kdelibs/
kdemultimedia/
kdenetwork/
kdepim/
kdesdk/
kdetoys/
kdeutils/
kdevelop/
kdewebdev/

Extragear is not matched exactly, too:
base/
graphics/
libs/
multimedia/
network/
pim/
plasma/
sdk/
security/
utils/

Is this intended, or should the submodules be restructured to match the main 
KDE modules? Matching the main modules would make it straigthforward to have 
the module coordinator also care for the corresponding playground submodule. 
Perhaps extragear structure should be aligned to the main modules, too? 
Because projects in playground could rather end there.

Motivation:
I want to give the projects in playground/utils some more visibilty by adding 
them to utils.kde.org, e.g. to show useful overviews of development status, 
similar to 
http://utils.kde.org/projects/kwalletmanager/development.php

So people are aware what is happening and do not continue to do things like 
implementing three power manager applets independently, like currently 
happening.

But this would mean binding of playground/utils to kdeutils. I am not sure if 
this is a good idea.

Comments, please?
Friedrich

-- 
Okteta - KDE Hex Editor, coming to you with KDE 4.1
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team