Putting Playground in some order

[Matt Rogers]

On Aug 19, 2008, at 4:58 PM, Friedrich W. H. Kossebau wrote:

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

I don't understand the purpose of this. The point of playground is to  
be a place where people can incubate ideas, share code, etc. Just  
because it doesn't see any activity doesn't mean that it's not useful.  
You're equating activity to usefulness and that's just not true, IMHO.

>
> b) KDE3 based projects are moved to branches/playground/ 
> kde3/$submodule/ (cmp.
> branches/extragear/kde3/$submodule)
>

this would be ok with me.


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

If it's in playground, translators and dashboard maintainers shouldn't  
even be looking at it anyways. IMHO, scripty shouldn't even be running  
on stuff in playground. However, I think automated code checkers  
should still be run (and why not? it's automated and requires somebody  
to look at the results first)


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

why should it?

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

I think it's intended. What works for the KDE main modules does not  
necessarily work for playground and/or extragear, and vice versa.  
IMHO, it's not necessary to have submodule maintainers for things in  
playground, because then it's not really a playground anymore.

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

I actually wouldn't do that, since then you're changing the definition  
of what playground is. I would instead make it an opt-in type of  
thing, and if you feature things on utils.kde.org, then you should be  
pushing those people who want something featured to promise to move it  
out of playground into extragear or kdeutils within a certain timeframe.

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

it's their time they're using, let them use it however they want to. I  
suppose you think it's a waste that there's like a bazillion audio  
players too, right?


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

No, it's absolutely not a good idea.

> Comments, please?
> Friedrich


Those are my thoughts. I know there have been other replies to this  
thread, but I thought i would throw my two cents worth in anyways
--
Matt