[RFC] Draft Roadmap for KDE 4.0

Sebastian Kügler sebas at kde.org
Tue Mar 6 10:35:33 CET 2007


On Tuesday 06 March 2007 10:02:24 Stephan Kulow wrote:
> Am Dienstag 06 März 2007 schrieb Sebastian Kügler:
> > What do you think?
>
> What I think? Good you asked. Because if you continue discussing on this
> level we won't have another KDE release before 2012.
>
> I like Tom's approach: Define a roadmap with milestones and set dates to
> it. If a milestone slips, define if you don't care about the milestone or
> the date.

I like it, too. The point is that for a roadmap, we need a match between a 
minimal set of features/requirements and dates. The relationship being: More 
features -> later releasedate, less features earlier releasedate, very 
basically. Tom proposed a set of dates (which makes sense to me, personally), 
so we have to find the matching set of features.

I am however not trying to push any requirements through.

> Don't take me wrong, nice kdelibs features will surely popup like mad every
> couple of days. But as a matter of fact: we managed to produce a pretty
> useful desktop with the crappy API just as well. While targeting for the
> perfect API dox and the perfectly designed APIs might sound like a super
> idea, it won't help me as a KDE user.
>
> So dear KDE release team: drop your perfection plans, drop all modules that
> do not comply to the roadmap and let them ship later.
> kdevelop won't make it? Fine, supply a KDE4 template for kdevelop 3.4.
> kdepim won't make it? Too bad, make sure kdepim 3.5 runs fine on a KDE4
> desktop.
> plasma won't make it in its full beauty? Define the bare minimum what is
> required and get as many hands to help as possible and deliver even better
> results for 4.1. I see good progress there, so I have a good feeling.

So what is this bare minimum? From your email, I understand:

- incomplete APIDOX is not a showstopper
- APIs may change in the future
- plasma not being completely finished is not a showstopper, focus needed on 
  making it usable
- either PIM 3.5 needs to run on KDE4 well or PIM4 needs to be usable
- KDevelop 3.5 needs to be usable to develop KDE4 applications well

> Every discussion around KDE4 pisses me at the moment actually as it's
> against the real aim a KDE4 roadmap should have: making sure a KDE4
> snapshot runs on as many desktops as possible. I can start any KDE4
> application at the moment and find easily tons of bugs and _that_ has to
> stop. If we break binary incompatibility 19 or 190 times in the timeline of
> KDE4 is _not_ the problem.

- binary incompatibility is not a showstopper
- stabilising applications should become focus now

> Sure every such case has to be evaluated as it hurts everyone not having a
> compile cluster, but I repeat: it's NOT our problem.
>
> A feature freeze in august 2007 is _way_ too late - may I remember everyone
> that we started porting for KDE4 in may 2005?
>
> People hear my message: STOP IT! NOW!

Personal note: I'm not out for a perfect KDE4 release, I'm trying to help 
making a decision on a roadmap, because I regard it important, and because 
I'd like to see more progress there. The problem is complex enough that we 
either need a benevolent dictator or a way to make this decision 
collaboratively. I'm trying to facilitate the latter.

Important question: Are there objections against the bullet points from 
coolo's list so far?
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I have no right, by anything I do or say, to demean a human being in his own 
eyes.  What matters is not what I think of him; it is what he thinks of 
himself.  To undermine a man's self-respect is a sin.  - Antoine de 
Saint-Exupery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/release-team/attachments/20070306/2af64d9b/attachment-0001.pgp 


More information about the release-team mailing list