Re: Putting Playground in some order
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
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
On Sunday 24 August 2008 10:16:22 Albert Astals Cid wrote: > A Dissabte 23 Agost 2008, Allen Winter va escriure: > > Howdy, > > > > The recent build problems in our kdesupport package dependencies > > needs to be addressed. > > > > I think we need to treat kdesupport libs just like any other external > > dependency. > > > > Something like the following guidelines: > > > > No KDE code (in trunk) changes should be necessary until: > > - a real release of the kdesupport package has been made AN > > - that release has been packaged by the "major" distros AND > > - an announcement about the needed upgrade is made in advance AND > > - people have had time (30 days?) to upgrade to the new packages > > > > For example: > > libfoo v1.0 is released. > > kde-packagers are notified to please provide packages for their distros. > > kde-devel and kde-code-devel are notified that within 30 days their > > builds will fail unless they have libfoo v1.0 installed -- that the > > distros have been notified and we hope packages will start appearing soon. > > > > People wanting to develop against libfoo v1.0 will need to do so in a work > > branch. > > Or using nice #ifdefs like we do in okular with poppler. > Sure. As long as we don't *require* people to upgrade to a new external package without a fair and timely notice. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: New screensaver proposal for kdeartwork
On Sunday 24 August 2008, Allen Winter wrote: > On Sunday 24 August 2008 06:26:12 Tom Albers wrote: > > Why not use the usual route[1] via kdereview? > > My fault. > I told Michael to come directly here because I didn't know how to handle > things since there is no module coordinator for kdeartwork. > > Toma is correct, first put the new screensaver into kdereview and then > let's give it the normal 2 week review period. Sounds good, will do so shortly. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
A Dissabte 23 Agost 2008, Allen Winter va escriure: > Howdy, > > The recent build problems in our kdesupport package dependencies > needs to be addressed. > > I think we need to treat kdesupport libs just like any other external > dependency. > > Something like the following guidelines: > > No KDE code (in trunk) changes should be necessary until: > - a real release of the kdesupport package has been made AN > - that release has been packaged by the "major" distros AND > - an announcement about the needed upgrade is made in advance AND > - people have had time (30 days?) to upgrade to the new packages > > For example: > libfoo v1.0 is released. > kde-packagers are notified to please provide packages for their distros. > kde-devel and kde-code-devel are notified that within 30 days their > builds will fail unless they have libfoo v1.0 installed -- that the > distros have been notified and we hope packages will start appearing soon. > > People wanting to develop against libfoo v1.0 will need to do so in a work > branch. Or using nice #ifdefs like we do in okular with poppler. Albert > > I need to get out of the habit of building kdesupport all the time -- we > should be relying on distro packages where possible. > > Comments? > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: New screensaver proposal for kdeartwork
On Sunday 24 August 2008 06:26:12 Tom Albers wrote: > Op zondag 24 augustus 2008 06:30 schreef u: > > Hi all, > > > > I'm writing to ask for permission to add the "KDE Asciiquarium" screensaver > > to > > kde-artwork, available from http://purinchu.net/software/asciiquarium.php > > and > > in playground/artwork right now as well. I think it's in a suitable shape > > by > > this point for KDE quality. I'm not sure what in the way of documentation > > is > > required for a screensaver but I can add that as well. > > > > Any feedback is appreciated as well of course. Please let me know if you > > have > > any questions. > > > > Regards, > > - Michael Pyne > > Hi, > > Why not use the usual route[1] via kdereview? > My fault. I told Michael to come directly here because I didn't know how to handle things since there is no module coordinator for kdeartwork. Toma is correct, first put the new screensaver into kdereview and then let's give it the normal 2 week review period. -Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: New screensaver proposal for kdeartwork
Op zondag 24 augustus 2008 06:30 schreef u: > Hi all, > > I'm writing to ask for permission to add the "KDE Asciiquarium" screensaver > to > kde-artwork, available from http://purinchu.net/software/asciiquarium.php and > in playground/artwork right now as well. I think it's in a suitable shape by > this point for KDE quality. I'm not sure what in the way of documentation is > required for a screensaver but I can add that as well. > > Any feedback is appreciated as well of course. Please let me know if you > have > any questions. > > Regards, > - Michael Pyne Hi, Why not use the usual route[1] via kdereview? Best, Toma [1] http://techbase.kde.org/Policies/SVN_Guidelines___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
