Putting Playground in some order
Friedrich W. H. Kossebau
kossebau at kde.org
Tue Aug 19 23:58:29 CEST 2008
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
More information about the release-team
mailing list