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

List:       kde-core-devel
Subject:    Re: KDE2 release schedule update
From:       Dirk Mueller <mueller () kde ! org>
Date:       2000-09-26 14:17:15
[Download RAW message or body]

On Die, 26 Sep 2000, Matthias Elter wrote:

> KDE2 v1.0 release schedule
> --------------------

well, I won't comment on the name change here anymore because everybody has
said already it's a completely stupid idea. The general rule is no numbers
in names, full stop. If you/we want to emphasize that its different from KDE
1, we have to think about a different name, but not extending it by a
number. call it KDE NT (new technology) or KNOME or whatever, but NEVER add
a number as a suffix to the name. 

(I could say about the klyx2 import a few days ago, but oh well...)

> Yes, this means that KDE2 is going to happen finally. After some discussions 
> at the meeting this weekend we came up with a rough post-KDE2 road map:
> 
> - Immediately after the KDE2 v1.0 release a KDE_2_0 branch will be created. 
> Fixes to this branch will be released as KDE2 1.0.X versions soon after the 
> 1.0 release. The KDE_2_0 branch is not open for feature commits.
> 
> - The HEAD branch is open for feature commits after the 1.0 release. We 
> however maintain kdelibs binary compatibility. The base applications will 
> probably see the most significant improvements. We aim for incremental rather 
> than revolutionary improvements this time.

This is the stupiest idea I ever heard. Please evaluate the following things
first before "hardcoding" this supposed-to-be road map:

- 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. 

- 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. 

- 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. 

- it will be a huge pain to keep parts of both branches to be interacting if
they're mixed. Imagine somebody installs a kdebase package from the feature
branch and still uses the kdelibs from the bugfixing branch. for any
non-trivial bugfixes or new features this simply won't work. there is no
doubt about that. Are you (it's not the personal "you == Matthias
Elter, it's the you as in "you == KDE developer) willing to spend your free
time on explaining each and every moron on this holy planet that they cannot
mix packages of those two branches? Believe me, they won't understand that. 
I'm working on the Qt GUI part of Licq and I'm getting about one mail a day
of a moron that is trying to install it on Redhat Linux and has problems
with it because Redhat 6.0 - 6.2 has never made it to ship a working Qt
version? All they ship is a strangely grabbed prerelease that is both binary
incompatible and crashing all the time. and the updates they have somewhere
hidden on their ftp servers only work if the users installs a new gcc and a
new libstdc++ as well? This is only a small example and I'm so angry about
that behaviour of Redhat because it pisses me off EACH AND EVERY DAY I go
to my computer for reading my emails.
The same will happen for KDE if we start two different "versions" of it. If
you didn't notice yet, the average intelligence of a Linux user is falling
faster than light speed, and I seriously doubt that this will change anytime
in the future. If you look in the newsgroups, you will clearly see that
most of them didn't understand a difference between KDE 1.0 and KDE 1.1.1 or
KDE 1.1.2. they don't even remember the version number they run right
now, they talk about KDE 1.2 or 2.1 or anything like that. some of them
don't even understand why they cannot compile a KDE1 application under
KDE2. Are you really willing to explain each and every butthead
that the third-party application they just downloaded will only work with
the KDE2 feature branch and not with the KDE2 bugfixing branch he has
installed?

- 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. 

- 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!

- who is going to write the documentation if we start a feature branch?
Since the Trysil event we have "dcop", the universal interface for scripting
every KDE2 application, which is basically the coolest thing mankind has
ever seen on any Unix platform. But nobody has noticed that yet because that
thing seriously lacks DOCUMENTATION and EXAMPLE APPLICATONS that jump
immediately in everybody's eyes who starts up KDE2 for their first time!
about 2-3 times per week there is some gnomee popping up on #kde channel
asking us why we dropped Corba for the components interface, and each and
every time you have to explain them why we chose dcop as it is not that
limited in use and far more faster than Corba. NO NON-DEVELOPER understands
that there is far more cooperation needed than just adopting the corba
buzzword. you need the same component interface, you need the same focus
handling etc. Nobody knows that because its nowhere documented!
If you browse developer.kde.org you will find a lot of documents talking
about how cool KDE2 will be as it adopted CORBA! There are a several
documents and example programs about that. You won't find much useful
information that is actually _up_ _to_ _date_. How do you expect
non-involved developers who WANT to develop for KDE to find the information
they NEED to develop applications for KDE 2?
If we start two branches, we will have even LESS time to update the
documentation and writing help files, that means almost no time if you
judge how many time is CURRENTLY spend on writing documentation!


Okay, there are a few more issues but these are the most important ones. My
suggestion is one branch after KDE2 release, open for bugfixes but new
features need approval by at least 2 other KDE developers. In
addition they needed to be tested and verified before checked into
the CVS tree. Bugfixing is HIGHEST priority. We will be flooded with bug
reports after release thanks to DrKonqi etc. so we NEED a product that can
SHIP ANYTIME. Whenever a serious bug pops up, we HAVE to be able to fix it
and release a seriously tested and working update any time in order to keep
the response time and our image loss small.  

KDE2 took so long time to finish because at certain points we made the
decision to throw away what we have and redo it from scratch
again(i.e. corba -> dcop). This must not happen again. Not opening up a
"feature branch" is the only way to ensure that we won't run into bigger
delay again. 

Thanks for reading,


Dirk

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