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

List:       kde-release-team
Subject:    Re: [RFC] KDE 4.0 Release Roadmap
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2007-03-15 16:45:50
Message-ID: 200703151045.54025.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On March 15, 2007, Andreas Zehender wrote:
> you have my vote :)

thanks =)

> 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 
those apps.

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 
4.0.

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 
this page:

http://extragear.kde.org/home/docs.php

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 
coordinated releases.

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 
main packages.

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 
solid.

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 
graphics tasks.

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)

[Attachment #5 (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]