[Panel-devel] RFC: release management strategy

Aaron J. Seigo aseigo at kde.org
Wed Aug 29 21:03:44 CEST 2007


hi all..

in the past kdesktop's plugins came from a few different places: libkonq for 
action menus (some c++, most .desktop files) and the dynamic wallpaper thing 
which pretty much didn't see any traction outside of kdebase/kdesktop itself 
and probably never had more than 3 or 4 plugins ever written for it.

kicker's plugins were several and largely redundant with each other (menus, 
extensions and applets) all of which had their base classes hosted in 
kdelibs. yep, the support for one specific app's plugins were loaded by every 
single kde app. brilliant, no? ;)

why am i rehashing that bit of kde history? well, it made the release strategy 
pretty simple:

- ship a bunch of stuff in kdebase
- shove a bunch more stuff in addons
- let other applications ship their own applets, e.g. kate's session menus 
shipped with kate (though konsole's was in with kicker =)

this seems a bit less than ideal, however. we also have the outstanding issue 
of what to do with all the items in playground/base/plasma/ .. personally, i 
am really liking how that is working. a lot.

i've never really liked kdeaddons, either. so here's my proposal:

- we keep the set of items in kdebase/workspace/plasma *minimal*. these should 
be core functionality items only. i'd like to have an irc meeting in 2 weeks 
time to settle on which those will be.

- we create extragear/plasma/ with subdirs for dataengines/, runners/, 
applets/, plasmoids/, scriptengines/ and possibly animators/ (if any new ones 
appear =). people move their own work as they want into extragear/plasma/. 
plasmoids/ would house non-c++ packages. we will cover which items to move 
over now at that irc meeting.

- we create a place for sample applets; perhaps in extragear as well? e.g. 
extragear/plasma/samples/ with all the subdirs under there? i don't want to 
lose all the samples; i think they are valuable and should be maintained. 
they shouldn't be installed, or shipped, by default but be there for 
documentary and educational purposes.

- there will be *no* plasma stuff in kdeaddons. this could be seen as my 
desire to kill kdeaddons outright, which would be accurate. ;)

then releases will happen like this:

- everything gets released with each KDE release, extragear included

- we do a source only snapshot release of plasma itself for our more devoted 
testers one a month. this is assuming KDE itself doesn't get into this game 
so we don't have to. but even if KDE as a whole doesn't do periodic 
snapshots, i want to for plasma. maybe plasma could serve as a test case here 
for the rest of KDE if need be

- we do a snapshot release of extragear every 2 weeks, hopefully as proper 
releases including binaries for as many platforms as possible. we need to 
look into availability of services such as OpenSUSE's build system as i 
really don't want to set up and maintain a network of systems ourselves =)

what this means is that we can get people trying out new addons all the time 
and keep the GHNS2 constantly repo fresh. it also means that kde releases are 
full of all the plasma goodies up to that point in time. hooray.

as the plasmoid community grows post-4.0, i'll be heavily recruiting people to 
move their stuff in extragear/. this is yet another advantage over kdeaddons, 
imho.

proposed irc meeting day: saturday sept 8th. please rsvp =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20070829/5e4c1d71/attachment.pgp 


More information about the Panel-devel mailing list