[RFC] KDE 4.0 Release Roadmap

[Allen Winter]

There's such much in here I don't even know where to start. :)

I suggest we get past the roadmap stage first.
Then take up the issue of what apps belong in $BASE vs. KEG.

A brand new thread in a week or two, perhaps?
-Allen


On Thursday 15 March 2007 12:45:50 pm Aaron J. Seigo wrote:
> 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.
> 



-- 
KDEPIM Developer
I accept PayPal payments to awinterz at earthlink.net