[RFC] KDE 4.0 Release Roadmap
Aaron J. Seigo
aseigo at kde.org
Thu Mar 15 17:45:50 CET 2007
On March 15, 2007, Andreas Zehender wrote:
> you have my vote :)
> maybe that's not the right place for this discussion, but KEG means I
> have to make separate releases?
not at all! =)
one of the procedures planned for a long time with KEG is to do releases that
coincide with KDE releases. the idea is that app developers can set
a "stable" tag on their code at whatever point they deem it releasable.
whenever kde goes into doing a release, the KEG mainatainer (Helio) will
first send out a reminder announcement (probably when the beta cycle starts)
and then when it comes time to release he will check out all of KEG that is
marked with that tag, ensure everything builds and then provide tarballs of
this has never actually been followed through with, however. so i spoke with
Helio the other day and we've committed to making it happen starting with
that means that as long as you simply set the right tag on your software,
you'll get a release of your software that goes out at the same time (and i
would hope with mentions in the announcements!) as the main KDE release. this
will bring greater exposure to the wonderful apps we have in KEG and relieve
one of the big "reasons" some people are reluctant to put their app in KEG.
btw, this is all noted in brief (Helio is set to add some more details) on
personally, i would hope that when kpovmodell is in KEG, that you remain as
involved in the kde graphics hacking community as you are now. in fact, as
i'll talk about in great verbosity later in this email, i hope that these
actions grow that community.
> Or do the distribution packagers include
> KEG in their distribution automatically?
depending on the distribution and the specific application. remember that
amarok, digikam, k3b, kst and others are all in KEG.
> I don't have the time to coordinate releases any more as I am the only
> half active developer in the kpovmodeler project and therefore want to
> participate in the normal kde release cycles.
that's understandable; and why i made sure we would have the KEG releases
going before suggesting this.
> I'm happy that porting is almost finished.
woo! i know, it feels like a huge party when that happens =)
> Why don't we let the packagers decide to split up the
> packages as SuSE does with the kdegraphics3d package?
what i'm about to suggest is not going to hold for all packages in kde as
there are different schools of thought. this is simply mine:
our main packages used to contain representative software for a given topic.
so pretty much all the good network related kde software was in kdenetwork,
for instance. many years pass and the number of people writing kde
applications has skyrocketted. do we put them all in the package? no: not
every author wants that, our packages would be insanely huge making release
coordination even more difficult, efforts to translate and document the "KDE
release" would mount ever upwards, etc. because of this, our packages have
become an odd hodge-podge of apps that are neither representative of "common
usage" nor even "best of breed" in some cases.
personally, i think we've outgrown the idea of packages as a container for all
apps of a given sort.
however, the packages -do- provide a very important support system for
application developers. namely, community support, improved visibility and
KEG has met some of these needs for some apps. amarok, k3b and digikam all
have excellent visibility and community support, but that's at least as much
due to them as it is to KEG. many other apps in KEG flounder in obscurity,
and not always because they deserve that =) on the flip side, how many people
know about kpovmodeller? so... neither model is working 100%.
my thought is that we should raise the importance, visibility and coordination
in KEG. this means primarily doing coordinated, opt-in releases of apps in
KEG. the currently stable versions, whatever they are at the time, of apps in
KEG should be released alongside the core module releases. this will allow us
to mention them in community announcements and press releases; it will allow
us to provide some release discipline as well as packaging help for those who
want or need it (amarok, for instance, neither needs nor wants it, and that's
OK under this plan too!). this will also allow us to adopt many, many more
apps than we can right now because of being concerned of "bloating up" the
eventually, i'd like to offer KEG applications some "certification badges"
that they can display based on meeting checklist items. this will help OSVs
as well as end users decide which apps are "more complete" or "higher
quality" (e.g. "more kde-rific" =) than others.
which leaves us with the main modules. the original goal of KDE was to provide
a complete desktop environment that would meet the needs of your general
desktop user. we've gone way past that, which is an awesome success on
everyone's part who has been a part of it.
i'd like to see the main modules get back to that spirit, however. our main
modules should, imho, be the collection of recommended applications for a
given topic that are of general interest and do the essential jobs. they
don't have to be the fanciest or "best", they just have to be usable and rock
by installing kdegraphics, one should be able to view any graphic format, do
basic editting and have some commonly used utilities like a screenshot
grabbers, ruler and color picker. the utilities are smaller and easier to
maintain which makes the ubiquity of their necessity less important while
making it harder to host them effectively (particularly for end users) in
KEG. so once you have installed kdegraphics, you are ready to do most general
the KEG graphics package, along with KOffice, should augment the kdegrahpics
package's basic set and open up the entire world of possibilities for you: 3D
rendering, advanced image creation and manipulation, photo management, etc.
this gives OSVs and users a really good set of guidelines to go by as to what
makes a basic, essential desktop from our perspective. having sat down with
people recently in fedora and gone through the packages one by one with them,
it's apparent we're not servicing them very well in this regard. i suspected
as much, but i'm rather sure that's the case now =)
it will also be key that kde-graphics and extragear/graphics are all part of
the same sub-community within KDE. i don't want KEG to be the divider it is
right now, community-wise. there are those who are quiet and reclusive by
nature, and that's great. but i want to signal to more app developers that by
being part of KEG they can join the general development community, which
includes the relevant main module hackers, even if their app isn't suitable
for inclusion in a main module.
this will get us away from the "4 packages that do $TASK" issue; it will let
us identify which are absolutely, must be solid apps (this has been an issue
with the 4.0 cycle for me); it will allow people to assemble basic desktops
easier by just following our guidance; it can strengthen our extended
developer community; and it will give more equal footing to all our
applications that may not be general purpose but which rock by putting all of
those apps in an actively managed and released KEG.
in that sense, i actually see this as growing our app devel community and
increasing the number of apps we endorse and ship without muddying the waters
of what a base KDE environment is and does.
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/release-team/attachments/20070315/3e57589f/attachment.pgp
More information about the release-team