Re: Putting Playground in some order
On Tuesday 19 August 2008, Friedrich W. H. Kossebau wrote:
a) Projects which have been without a commit for more than five month are
moved to
tags/unmaintained/playground/$submodule/{3,4}
not really. playground is not maintained so moving stuff from playground to
unmaintained does not mean anything to me.
b) KDE3 based projects are moved to branches/playground/kde3/$submodule/
(cmp. branches/extragear/kde3/$submodule)
I think that makes sense.
So people are aware what is happening and do not continue to do things like
implementing three power manager applets independently, like currently
happening.
playground stuff is supposed to appear and disappear at any time, so attempts
at documenting them at utils.kde.org is either very time consuming or always
out of date. I'm not opposed to document playground stuff (quite the contrary),
but keeping the documentation at a completely different place (other than a
README within the subdirectory) is likely to run out of sync fairly soon
again.
How about enforcing (by policy) that each app/dir whatever must contain at
least a INFO or a README file that describes wht the purpose is, who is
working on it and who should be contacted regarding the code?
Greetings,
Dirk
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Putting Playground in some order
On Monday 25 August 2008, Dirk Mueller wrote: How about enforcing (by policy) that each app/dir whatever must contain at least a INFO or a README file that describes wht the purpose is, who is working on it and who should be contacted regarding the code? Well, it's allready the case, each subdir contains an INDEX file which is supposed to contains the name of the apps, a description, authors and even a link to a webpage. But a lot of applications are missing in those INDEX files. -- Cyrille Berger ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Putting Playground in some order
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=playgroundmodule=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
Re: Putting Playground in some order
On Tuesday 19 August 2008 17:58:29 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. I agree we should cleanup every now and then -- certainly the dead stuff should be removed. And I agree that kde3 apps should be moved into a substructure. Keeping mostly the same top-level structure is also a good idea. Doesn't have to be exactly the same as trunk/KDE. However, I don't want to give too much formality to playground. We want people to feel free to explore ideas and stuff. In summary: - how about an widely disseminated email asking people to remove dead code and to move their kde3 stuff into playground/$module/kde3 I'm not so sure that we should be moving old playground code into unmaintained. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
