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

List:       kde-core-devel
Subject:    Preparing for KDE 3.0 (Was: Re: What to do after 2.2?)
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-07-15 14:44:46
[Download RAW message or body]

On Sunday 15 July 2001 15:49, Dirk Mueller wrote:
> Therefore it would be great if Redhat (which is usually the distribution
> which makes most of the problems) could state on when they intend to switch
> to gcc 3 - as gcc 3 is anyway binary incompatible to their 2.96 invention
> we should be able to release a Qt 3 based version at that time.

Aye... I am a strong supporter of the KDE 3.0 move, but I think doing this 
would be a bit too much of a rush. Between KDE 2.1 was released on 26 
February, 2.2 is scheduled for 30 July, so we have had a release cycle of 
about 5 months. I don't think we can improve on that much for 3.0, so we'll 
have KDE 3.0 out by the end of november/december this year. We definitely 
miss this fall's distros this way.

Maybe we should setup a document describing the tasks that _must_ be done to 
KDE during the transition to 3.0 because they cause BC problems when done 
later. This document should be done _now_ so we have a nice checklist to work 
on as soon as KDE_2_2_RELEASE is tagged in CVS.

Such a checklist could speedup development because we have a clear (and 
fixed!) set of goals before we start. The idea is then to implement the list 
and immediately head towards KDE 3.0 release once the list is done. No other 
BC-dependent features but what we decide between now and about a month when 
we just started working on KDE 3.0.

There should be a _very_ strict policy regarding the addition of more 
BC-dependent stuff after we 'froze' the checklist, so we can have the release 
cycle as well prepared as we can possibly do it and thus cut down on it. If 
someone adds non-BC features like we do normally during the release cycle, 
fine. But for once that should not be the main concern. KDE 3.0 should IMO be 
announced as the basis for the next 2 years or so, leveraging the KDE 2.2 
code base on top of Qt 3.0 and does not necessarily need new features.

What are the opinions regarding this list? Should we do it? If so, how should 
it be maintained? A KSpread document in KDE CVS might be an option, or a 
plain text doc, or a web page or whatever. Putting it in CVS makes sure 
everyone can add his wished. OTOH, discussing wishes here and/or on kde-devel 
quickly and having one person maintain the list might be a better solution. 
Both approaches actually have their merits.

I am willing to setup and maintain the KDE 3.0 checklist, but I do need some 
input regarding the way how we should do it and whtether we should do it at 
all. Also note that my cable modem has a crappy serial connection so I will 
_not_ host a web site on my server. If we go for a web site I do need web 
space somewhere.

Martijn

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