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

List:       quanta-devel
Subject:    [quanta-devel] KDE 4.0 release plan
From:       Andras Mantia <amantia () kde ! org>
Date:       2007-03-15 21:03:35
Message-ID: 200703152303.35542.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi,

 some days ago a release plan for KDE 4.0 was posted on the 
kde-core-devel list and it is up for discussion. Unfortunately there is 
no such team as KDEWebDev anymore, as much as I would want to see it, 
but I still post this information here and I'm waiting for comments and 
discussion, maybe there are still some people reading this list.
So first shortly about the plan itself, the important points for us: 
1) 1st of April 2007: some kind of freeze in kdelibs. As this date is 
quite close, it might happen that some KDE libraries will not be in the 
4.0 release! Trunk should contain only KDE4 code, which for us means 
that we should remove Kommander from trunk. Kommander was never ever 
ported to KDE4, while the rest of KDEWebDev was at least ported in a 
sense that it compiles and links with Qt4 and KDELibs4. Kommander is 
simply disabled from compilation. So the question is: what will happen 
with Kommander???

2) 1 June 2007, Feature Freeze: basicly it means that any of our 
applications should be feature ready in 2,5 months.

3) Start: 25 September 2007, Release Candidate. So the KDE 4.0 release 
should be expected around October.

My opinion about the plan was that the KDE libraries freeze is too 
close, but the majority (from the release-team mailing list) was in 
favour of 1st of April. But this issue doesn't affect us as application 
developers that much, it rather helps to work on a more stable base, so 
we can take an early freeze as a good thing, except that it might not 
have KNewStuff2 in, for example.

More important is the Feature Freeze on 1st of June and the release is 
September. KDEWebDev contains the following applications:
- KFileReplace: as far as I know there was no other development than 
script porting and porting done by Laurent Montel.
- KImageMapEditor: as I saw the author, Jan Schafer worked on the KDE4 
version, so this is GOOD.
- KLinkStatus: from the commits I think Paulo is working on it.
- Kommander: as I said nothing was done
- KXSLDbg: as far as I see it is the same issue as with KFileReplace
- Quanta: some parts were ported, some new parts were started, it is 
very unfinished, but see below.

The module might be released with only some applications from it, and 
this is a real possibility not only in case of KDEWebDev, but other 
parts of KDE as well, like KDEPIM or KDevelop. That means that is very 
much possible that the KDE 4.0 release will not contain ALL the 
applications from KDE 3.5.x, and it might even miss some important 
apps, like KMail. Also from the discussions it became clear the KDE 4.0 
might be just some kind of intermediate release between the 3.x series 
and the 4.x series, in the sense that the next KDE release might break 
library binary compatibility. Some even suggested to name it as KDE 
3.9. ;) The idea of doing the release as the plan says is that KDE 4 is 
already late and without such plan it would be never ready and in worst 
case Qt5 might come out before KDE 4.0. :-(

Taking into account the above, I think that in kdewebdev the situation 
will be that it gets released without Kommander and Quanta, or in worst 
case only with KImageMapEditor and KLinkStatus. Why? Because releasing 
a version which is inferior to the KDE 3.5.x version is worse than not 
releasing at all, as the old version can still be used under KDE 4. 
If - for example - KFileReplace works just as good with this automatic 
porting (and some refinement) as the 3.5.x version, but doesn't offer 
any new features or even new bugfixes, it can be released.
Releasing Kommander is out of question right now as its development was 
not started at all.

Now about Quanta... There are several problems with Quanta4. One is that 
right now Quanta development is a one person job and that person is 
kind'a lost the motivation. That would be me, and the lost of 
motivation is several:
- there is a high amount of work which means get the old code, split it, 
create new plugins from it and try to make it to work as good as the 
old one. Work which is not so demanding (when its about thinking), but 
can take a lot of time.
- I'm alone. Working in a team is so much better and more motivating. 
Jens helped with Quanta4 a lot and I enjoyed when he was here. We made 
good progress both times, even if last year I was on a point to throw 
everything out due to performance issues. Jens moved back to Germany 
from Cambodia not so long ago, I don't even know if he has an internet 
connection right now, but I'm sure he is busy with his (new) life....
- some things have changed in my life as well: a baby and an illness 
which doesn't want to go away.

For this reason the Quanta4 development is almost stopped. Whenever I 
sit down to work, I enjoy much more to do some hacking on the old 
Quanta (and there is plenty of things to do - fix - there as well!) or 
on some website ;-). This might be because I'm more familiar with that 
code and also because such kind of hacking is usually bugfixing and I 
get feedback for the work. While the Quanta4 work is something that 
might hit the users only in several months (the best scenario), and 
until then if I'm alone almost nobody will even try to start Quanta....
That is about me. But there are also technical reasons why Quanta4 
development is delayed. Quanta4 is radically different in the 
architecture from Quanta3. The latter was a monolithic application, the 
new one is plugin based using the KDevelop platform. The new code is 
more understandable and documented and I like it very much and I'm sure 
in the end it will be fun to hack on it. KDevelop suffered also a 
rewrite between KDE 3 and KDE 4 and it is very likely that they cannot 
keep up the KDE 4 schedule. This is one of the reasons why Quanta 
cannot keep it up as well. There were times when I very much disliked 
what and how is happening inside KDevelop and I even thought that we 
should go on our own way, but the benefits of sharing the 
infrastructure are soo big, that we really should try to overcome the 
problems and work with them. For example if we just think about the UI: 
there won't be any MDI library in KDE4. KMDI is dead and we have to use 
the UI developed inside KDevelop, otherwise we have to write our own 
UI... Of course sharing things like VCS integration or find & replace 
is also a big plus for us.
 I have to see again where are they, hopefully in much better state. 
The second technical problem is the parser. Last year we wrote a new 
parser with Jens, which is very nice, is quite well documented, seems 
to work, but .... only for XML, only for initial parsing and doesn't 
build a real node tree. As you can see we have lot of things to do with 
the parser and if we don't do it, it basicly means that we cannot 
really progress in other parts as well. 
 From the above issues the node tree question is the important one. 
There were high hopes the KDE4 will have a KHTML (khtml2) that is 
easier to use and that we can store everything we need in KHTML and 
this way we can do a clean and good implementation of the WYSIWYG mode. 
I think this will not happen. Jens might disagree with me, but for me 
using KHTML for storage as of now is a dead end and we should go back 
to our own tree. And if nobody will help to test and work with KHTML as 
a DOM storage this is what I WILL do. What does it mean? It will 
probably mean that there won't be any VPL mode...
 Parsing non-XML parts needs some state machines. This is not that hard 
to do, and probably it is fun as well. Parse-while-type is the biggest 
challenge. I have some experience with it, and I know how much headache 
it can cause. Actually right now I'm debugging some crashes in 
Quanta3's parser which are most likely caused by this part of the 
code...
 Still, even without a complete new parser there are parts of Quanta3 
which could be spearated and ported to KDE 4, one thing that comes into 
my mind is the CSS editor. Any volunteer for this?

So this is about our future. Not so bright, but not black.

And here is the original RFC about the release plan. KDEWebDev related 
comments can come as a reply to this mail, generic Release Plan 
comments should go directly to kde-core-devel:

--------------------------
[RFC] KDE 4.0 Release Roadmap
From: Allen Winter <winter@kde.org>
To: kde-core-devel@kde.org
CC: KDE release coordination <release-team@kde.org>
Date: 2007-03-14 14:22
   
  Howdy,

Hereby we, the Release Team, present a draft KDE 4.0 Release roadmap 
which has
been discussed on our mailinglist the past few weeks. It's an optimistic 
schedule
that aims to release in late October, based on 3 Beta's and 2 release 
candidates.

We tried to make a schedule that pleases as many people as possible, but 
you
will understand that everyone has their own favorite agenda. So when 
commenting
on the schedule you will need to think about who will benefit from the 
change
and who will have trouble with it. Your personal interest might not be 
the one
of the group. 

KDE 4.0 will not contain all features announced nor promised: these will
come during the lifetime of KDE 4.  We can probably switch quickly to a
KDE 4.1 release if there are major subsystems ready for merging soon 
after
the KDE 4.0 hits the streets. Also remember that we have been porting 
for
a couple years and we need to get this show on the road.

Release soon and release often.

Discuss.
Allen, KDEPIM Release Dude

PS: there still remains a great need for people to volunteer as release
coordinators for several of our modules.  The current coordinators list,
along with other KDE 4 Release info can be found at
http://techbase.kde.org/Projects/KDE4ReleaseInfo

It would be great if we had at least a point of contact per KDE module.

KDE4.0-Roadmap.txt
  KDE 4.0 Roadmap
===============

Milestone: Subsystem Freeze
Date: 1 April 2007
Goals:
 * From this date forward, no major KDE subsystem can be committed to 
kdelibs.
 * The location of all classes are fixed within kdelibs
 * Trunk is expected to contain KDE4 code only now. This effectively 
means
   that all scripts processing translations for KDE3 in trunk will 
cease.
 * Extragear applications that want to release based on KDE3 are 
expected
   to move to /branches/stable and work from there.
 * The buildsystem requirements are fixed; i.e, must not require a
   version of cmake greater than 2.4.5.

Milestone: Alpha Release + kdelibs soft API Freeze
Date: 1 May 2007
Goals:
 * Qt 4.3 is required from here until release.
 * The kdelibs API is frozen. This means that the classes and interfaces 
are
   not allowed to change, except with permission of the core developers.
 * To make an API change, post a kdelibs API exception request to the
   kde-core-devel mailinglist with an explanation and the code. If there
   are no objections after a week, the change can be committed.
   NOTE: all affected modules must continue to compile and work as 
expected.


Milestone: Feature Freeze
Date: 1 June 2007
Goals:
 * The KDE main modules are frozen for new features.
 * No new features are allowed, the focus is on stabilizing the 
applications
   and fixing all bugs.
 * The main module maintainers must indicate if they will follow the 
release
   schedule or will divert and not be released together with KDE 4.0.


Milestone: Beta Cycle, Full kdelibs API Freeze
Start: 25 June 2007  End: 24 September 2007  Duration: 3 months 
(estimated)
Goals:
 * From this date forward, a Beta Version will be published every month
   until most grave bugs are resolved.
 * The kdelibs API is now frozen solid.
 * Translations are included starting with the second Beta, thus 
beginning
   a string freeze. Exceptions can be requested on the kde-i18n 
mailinglist.


Milestone: Release Candidate Cycle
Start: 25 September 2007  End: 22 October 2007  Duration: 4 weeks 
(estimated)
Goals:
 * From this date forward, a Release Candidate will be released every
   two weeks until *all* grave bugs are resolved.
 * After the first Release Candidate there is a total release freeze.
   This means only regressions (breakage caused due to the KDE4 port)
   or grave bugs can be fixed, but nothing else.
 * With the first Release Candidate, a list of languages which will be
   included with the KDE 4.0 release will be made available, based on 
the
   usual rules.


Milestone: KDE 4.0 Released
Date: 23 October 2007
Goals:
 * This date is based on an estimated 3 Beta's and 2 Release Candidates.

-------------


Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org

[Attachment #5 (application/pgp-signature)]

_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel


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