[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