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

List:       kde-core-devel
Subject:    Re: KDE2 release schedule update
From:       Matthias Elter <me () caldera ! de>
Date:       2000-09-27 11:55:38
[Download RAW message or body]

On Tue, 26 Sep 2000, Dirk Mueller wrote:

First of all, please also read my answer to Waldo.

> - everybody reading kde-bugs-dist or kfm-devel will know that we're flooded
> with konqueror/khtml/kjs/kjava related bug reports. The are a huge amount
> of issues left, i.e the referer problem or form post/cookie problems that
> make konqueror/khtml unusable for real world usage - so many of
> them that I'm unsure if it is a clever idea to release KDE2
> currently at all - remember the GNOME 1.0 effect. But as this seems to be
> decided lets not discuss it again.
> The important point is: we will need to do a lot of changes to
> khtml/kjs/kjava. None of them only qualify as "bugfixes", because most
> problematic webpages we get reports on rely on certain unimplemented
> features in the lib. this means that all commits would go to the
> KDE_2_0_BRANCH, leaving the bugfixing branch behind.

KDE 2.0.1 is intended to fix the most critical bugs the large user base we 
will have as soon as it is adopted by the distributors will find. Problematic 
web pages are not critical. I can work with KDE even if kthtml can't render 
ww.foobar.com. I can't work with KDE if say kwin crashes every 2 hours on 
certain systems. 

> - We lack of resources maintaining two different branches. as you can see
> several non-core developers even now don't run KDE2 but only develop for it
> under KDE1. This situation will be worse if we split KDE2 in two different
> branches. There will be almost no people who regularly checkout both
> branches and see if they still work. So the quality insurance of one of
> those branches (and my guess is it will be the bugfixing branch) is equal
> to zero. That's insane. KDE was getting good in the past because every
> developer runs it all the time, so he actually triggered all the most
> common issues somewhere in the code by himself. This won't happen any more
> with the above schedule, because I know that every developer likes to work
> on new features instead of doing bugfixing and optimizing. So there will be
> a huge number of new feature commits in the feature-branch, which will
> diverge both branches even more, making it less possible to apply the same
> bugfix in both branches with acceptable amout of work.

The KDE_2_0 branch wont live longer than a few weeks. As I explained above 
it's only purpose is to release a version of KDE 2.0 that fixes "show 
stoppers" we find after the "show" (and we _will_ find some) fast. It is also 
important to have that branch to be able to fix security problems people find 
in KDE 2.0 fast. Those of us who are paid to work on KDE by a company who is 
interested to have a 2.0.1 release soon after 2.0 (and I bet all distributors 
are) _will_ have to commit  fixes to the KDE_2_0 branch.

> - try to learn from the linux kernel development. they don't do much right,
> because they don't use any source versioning system like CVS etc., but even
> they know that its a bad idea to launch a bugfix and a new feature branch
> at the same time. We should get stable what we have and make it better in
> small steps. if there is a new feature or two in the bugfixes it makes the
> people happy and actually makes them willing to upgrade.

As I said, the branch wont see any bugfix commits other than fixes for 
critical bugs or security holes. You can't compare this to the stable 2.2.X 
kernel branch that sees feature commits.

>
> - think about the distributors. they constantly have the problem of too
> less space on too few CDs. do you think they will ship the KDE bugfixing
> branch as well as the KDE feature branch on their CDs, besides GNOME and
> half a dozen other windowmanagers? They will decide for one of them, either
> the bugfixing branch or the feature branch. If they decide for the
> bugfixing branch, it's a bad decision for us because nobody will notice
> that KDE2 actually evolves, that means it adopts new features and got new
> eyecandy applications. That's like a shot in our own foot.
> on the other side, if they decide on the feature branch, they will never
> ship a seriously stable environment because that branch isn't supposed to
> be stable. This will not only be a shot in our foot, but also in our head
> because it kills of biggest advantage over competing desktop
> environments: being stable _and_ useful.

Hm? Distributors will ship KDE 2.0.1, the fixed version of KDE 2.0 until we 
release KDE 2.1. What is your point? We wont have bugfix/feature branches 
like the Linux kernel has!!!

> - think about the i18n teams. Do you really think they will translate both
> the bugfixing branch and the feature branch? They asked us about a string
> freeze _months_ before KDE2 release because they want to catch up with the
> new strings introduced! they won't be happy about that desicion that
> effectively doubles their work!

Same as above, this is not about linux kernel style bugfix/feature branches! 
There wont be message changes in KDE 2.0.1.

(...)

> Thanks for reading,

It was a pleasure. Although I could have enjoyed it even more if it was a 
little bit shorter and to the point. ;-)

Greetings,
Matthias

-- 
    _____     ___
   /  __/____/  /                Caldera (Deutschland) GmbH
  /  /_/ __  / /__           Naegelsbachstr. 49c, 91052 Erlangen
 /_____//_/ /____/          Matthias Elter,  email: me@caldera.de
==== /_____/ ======   phone: ++49 9131 7192 300, fax: ++49 9131 7192 399
 Caldera OpenLinux                  http://www.caldera.de

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