[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: the future of kdetoys
From:       Sebastian Kuegler <sebas () kde ! org>
Date:       2008-05-07 21:59:05
Message-ID: 200805072359.12961.sebas () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 07 May 2008 23:08:32 Dirk Mueller wrote:
> On Wednesday 07 May 2008, Stefan Böhmann wrote:
> > In short: I think the kdetoys module is dead.
>
> even in KDE 3.x times it was used as a testing module for build system
> changes (because it is small and compiles quickly) :)
>
> I think I'm fine with moving the stuff into an extragear module and just
> not releasing it together with KDE. on the other side, it contains useful
> stuff.

Tom makes extragear tarballs that go with KDE releases. This also solves 
the "does releases" part of the "has no maintainer" problem.

> > 3. eyesapplet
> > and the same here. But here I could't find an alternative plasmoid yet.
>
> noone has written an eyes plasmoid! OMG! thats a nice weekend job for a new
> developer, isn't it :)

We should file a wishlist item. 

> > So the final question is, should we possibly keep kdetoys with only
> > one "utility"? Or should we move this application(s) to kdeutils or
> > extragear and remove kdetoys entirely.
>
> I agree, but we should maybe introduce another module that can be used as a
> collection of useful plasmoids (e.g. a new name for extragear/plasma). I
> would suggest kdeplasmoids.
>
> the reason for that is that the idea of releasing extragear/plasma together
> with KDE was good, but it wasn't practical as plasmoids in there kept using
> the latest API and so even with KDE 4.0.1 (or 4.02) it wasn't possible
> anymore to release it. by creating a module that goes with the regular KDE
> branches we can fix that.

For Plasma, the API will now calm down after the last nasty weeks, so it's 
becoming less of an issue there. OTOH, it's a general problem if apps in 
extragear require newer kdelibs while you would want to ship them with x.y.z 
releases. Tom probably knows more about that.

But yes, branching those candidates together with x.y.0 releases sounds like a 
reasonable solution. That also makes it possible to not have a feature freeze 
in trunk/extragear, which is I think an interesting idea.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 

["signature.asc" (application/pgp-signature)]

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


[prev in list] [next in list] [prev in thread] [next in thread]