This is the KDE developers’ point-by-point rebuttal to Neil Stevens’ charges,
published here Saturday, that “KDE 3 has been mismanaged…” Read the complete text below or see it
here. )
List: kde-core-devel
Subject: Re: KDE Development Policy
From: Dirk Mueller
Date: 2002-03-09 12:03:28
[Download message RAW]
On Fre, 08 Mär 2002, Neil Stevens wrote:
Hi,
> 1) Packages missing from the release entirely (1)
That was correct for a few hours after the rc1 announcement, in which I took
a round of sleep. I fixed the problem immediately after waking up and
talking with Stefan Westerfeld for coordinating the version number increase.
> 2) Rampant compile problems
Like ?
Indeed there are problems on non-gcc platforms, which made us require
updating the admin directory to a newer libtool version. However, thats your
point 3 already.
> 3) Last-minute changes to build requirements that cannot be met by
> many developers without an operating system upgrade (2)
Sorry?
Let me put the facts straight:
- The libtool update got necessary because of the RPATH encoding problems
in the previously using libtool version. Furthermore the previously
used libtool version was a dead end as well. It was the heavily
self-patched version of a forked version of an outdated libtool
development branch that never made it into any libtool release IIRC.
- The libtool update was indeed very late, thats correct. But you have
to remember that the _preparation_ of the update took some time as well
(integrating libtool HEAD, fixing all the bugs in it, testing compilation
under many setups). I personally can not judge about if this step was
"good" or not, but I have to trust Michael Matz and Stephan Kulow upon
this decision.
- the libtool update does _not_ require an operating system upgrade.
autoconf is a perl and m4 based package of less than 1MB size in source.
compiling and installing it takes less than 5 minutes, it is compilable
out of the box on about each and every broken system you can think of.
Furthermore many newer distributions ship it by default anyway.
If you upgrade your operating system instead of updating autoconf its
your decision and not forced by KDE itself.
- The build requirements update was a step to do anyway. We simply can not
keep the compatibility with autoconf 2.1x and 2.5x over a longer period
of time. For my personal opinion, adjusting the build requirements is
better done for a major release like 3.0 instead of a "normal" release
like 3.1.
- autoconf is only required during make -f Makefile.cvs, which is not
supposed to be run by the user who compiles KDE from source. They will
download the tarballs and configure it just like all the tarballs before,
even if you have an older version of autoconf.
- If you think about it, almost all Linux distributions had to replace
our outdated build system because it did not support many of platforms
people want to use KDE on, like ia64 in example.
- If you really consider the libtool update to be a problem, then feel
free to:
a) fix libtool to work with older autoconf versions
b) maintain an "admin.old" directory with the older checkout for
people to download and use. However I almost bet that replacing the
admin dir before compiling is even more work than updating autoconf.
> 4) Many outstanding bugs (3)
Again, let me put the facts straight:
- The incoming flow of bugreports is greater than
the rate of fixed bugs for quite a while already. so its quite natural
that there are many outstanding bugreports.
- Many of the incoming bugreports are reported against KDE 2.2.0 or
2.2.1 and not reproduceable with CVS HEAD any more for quite a while.
Do you really want to delay the release of 3.0 even more to collect
even more bugreports about "obsolete" KDE versions that almost nobody
(except Laurent from Mandrake) develops against ?
- If you have a look at bugs.kde.org, you will realize that the amount
of open bugreports went down rapidly during KDE III meeting. With
the exception of khtml, which has about 800 open bugreports, and konqueror
with about 380 open bugreports, every package has less than about 50 open
bugreports, with many many less than 10 open ones.
Except for khtml problems I would say KDE is in a pretty good shape
right now, if you measure it by looking at the amount of open bug reports.
- With the size of KDE and the amount of apps and the amount of users
its unrealistic that you will reach the "open bug reports == 0" aim
at _any_ time.
If you have a better solution for scheduling the KDE release for a time when
there are no open bugreports (or a way to achieve that), please let me know.
> 1) When users and developers cannot build KDE, they cannot test KDE
Those who can not build KDE and think its a KDE problem, should report the
problems so that we can fix them.
> 3) When the credibility of the KDE release policies are called into
> question, users and developers are less likely to feel that
> testing is of value, and stop participating.
Okay, this might be painful for you to realize now, but what do you think we
should do? update it after 3.0 ? screw kdevelop users who will not realize
that their next minor update will have a new admin directory that is
incompatible to their older one ? Wait for 3.1, which is probably not to be
out before christmas ? Screw all the platforms then that need the newer
libtool ?
The only solution I see currently is providing a "configure" script for
"make -f Makefile.cvs", that will pick up the "right" admin dir. I will ask
Stephan and Michael to consider this.
> The credibility of the release policies are further damaged by the
> manner in which the decisions are made. For instance, the major
> change to libtool, there was a minimum of discussion, with no
> compelling bugs or reasons shown for making this drastic change.
There were always major changes in the build system before a release
to overcome certain platform incompatibilities.
> The only remedy left for these KDE 3.0 ailments is to apply a "hard
> freeze" to the KDE 3.0 source, release a third beta, to begin allowing
> serious testing of KDE in real situations.
Well, I'm actually doing that. Maybe even more people. I can't "dictate"
anybody to do that though.
> For KDE 3.1, however, more can be done. Having identified the
> failures of KDE 3.0, we can trace the causes of these failures, and
> avoid causing them again. As was already stated, the difference
> between KDE 3.0 and recent releases has been changes in the "freeze"
> policies in the period leading up to the final release.
Again, let me put the facts straight:
- KDE 2.0 development was in large ways different to KDE 3.0 development.
There were _big_ architectural changes in kdelibs. We had to concentrate
on getting it to work a lot more than with KDE 3.0, which is basically
a port of KDE 2.0 with a considerable amount of fixes and improvements,
but no major achitectural changes.
- The mail with Waldo / Mosfet you quoted in your mail was _exactly_
about _long_ _freeze_ periods and the way it annoyed the developers.
Therefore I tried to learn my lesson and made the 3.0 release schedule
more open for developers. This was for example the case with the feature
plan and the shorter "deep freeze" period. I do want to give the
developers a bit more freedom, to keep them happy and not feeling pissed
by my "the release coordinator has spoken" - rants. Maybe I was too
loose this time, so probably we find the golden way of doing things for
KDE 3.1.
- I'm really pragmatic about the freeze. I do see commits on kde-cvs
that I "don't like" either, but I usually don't try to rant the people,
but instead check out the diff and try to review it. I actually
do find bugs in the commits then from time to time, but usually I don't,
mainly because I'm not familiar with the code in particular.
In my opinion, if more people would do the same we would have a much
higher level of quality ensurance than enforcing with brute force a
"freeze period". the code doesn't fix itself nor does it become
better if you don't touch it for a while. the stuff only moves
forward if there are people who are motivated enough to constantly
_push_ _it_ _forward_ instead of let it rot in the state it is.
Unfortunately I see far too few replies to "broken" commits on kde-cvs,
but again I'm not in the position to change it myself. I'm not a
dictator of KDE and I don't want to be.
Therefore, a freeze
period is supposed to be a "mental barrier" for developers to make
them think "lets make sure it works" instead of "lets implement
this new cool feature". It doesn't necessarily mean that the amount
of commits is going down, at least not IMHO.
> >From the time of one week before KDE 2.2, until the final release, all
> changes to the source had to be reviewed on the KDE mailing lists
> (save, of course, trivial changes whose differences are included in
> the log message). (4)
The same is currently happening as well. Of course there are some patches
that are so obvious that they don't require a review (this is a difficult
rule though. as somebody might think something is safe while another one
knows that it will horrible break things).
> The justification for these changes was
> explained very well by the KDE 2.2 release coordinator Waldo Bastian
> in a mail to the developers (5), in which he said "[Y]ou will have to
> respect release freezes" if you put your code into KDE.
Hmm, I always tried to express that more gently, but if you find Waldo's
mail okay, I will quote it in my next regular-rant mail ;)
> In contrast, the time leading up to KDE 3.0 RC 1 is best described as
> a flood of un-reviewed changes to the sources. (6)
I don't agree here.
> The flood was met with excitement, to be sure, because the flood
> came from a rare opportunity for roughly 20 KDE developers to meet in
> person and develop. This opportunity was not to be passed up, but it
> could have been handled differently.
I'm sorry. But sitting together in front of the same computer and hacking
and discussing the same sourcecode is a lot _more_ efficient than making
a patch, posting it, realize there was an error in it, and then remake it.
We were also greatly influenced by a tool that allowed to rebuild KDE in a
distributed way. this way a complete KDE rebuild only took a few minutes
instead of several hours. I understand that it might have been difficult to
keep up witht he commit rate at that time, but still I think it was worth
it, because KDE benefited from it over all.
Remember, putting so many developers in the same room also made us realize
regressions _much_ earlier. For example people were notified about errors in
their commits within a minute range instead of hours/days range during the
usual "development".
> If the developers in in the meeting felt that avoiding the mailing
> list was the best way to maximize use of the meeting, then they easily
> could have proposed a delay in the KDE 3.0 release, to allow for more
> time to stabilize after the meeting, to allow for testers to catch up
> with their time of great productivity.
Well, the 3.0 release dates are not fixed, they are suggestions. In general
it will be delayed when necessary (that is when people indicate in mails or
irc messages to me that they urgently need more time).
If you remember, you suggested a delay of 3.0 release by one week, and it
happened afterwards, didn't it ? Is it not okay that I don't decide this on
my own but instead wait for people asking me to actually have more time ?
> Some have suggested a failure in the community-recognized leadership
> of the KDE 3.0 release. While Dirk Mueller is respected throughout
> the community, his ability to step in and enforce the policies and
> release plans that everyone agreed to in the past has not been shown.
Sorry ?
Isn't it _you_ that is asking for _changing_ the release schedule that we
agreed on before ?
Again, please remember that I'm not the one who will sit there with a loaded
gun and waits for somebody breaking the schedule. If you want a dictator or
a person who manually confirms every commit or every change to KDE, then I
am not the right person for this. In addition I claim that you will find
nobody else in the KDE developer community that is going to do that and will
be accepted. So, as a result of that, all I can do is trying to keep the
people reasonable and establish the communication between the developers
with different interests. Therefore I would not have ignored or refused a
message from you telling me about your concerns with the libtool update (as
an example). But instead you decided for a public rant, that makes the KDE
development community look like a heap of fools who can't organize
themselves. Again, I can't prevent anybody from doing that, but in general I
would like to suggest to actually _try_ it the _regular_ way before starting
to rant. It would make us look a bit more professional.
Please don't understand the release coordinator job as a dictatorship role.
It is clearly not.
> Many in the community rely upon KDE, and as Bastian wrote, development
> of the KDE release carries responsibilities as much as it does
> privileges, and Mueller has not held the developers to these
> responsibilities.
The responsibilites have to be accepted by all developers. I can try to be
more strict about enforcing the rules, but not so long ago I can remember
somebody who tried to sneak in a new plugin for noatun just because
"somebody else did something similiar". In my opinion this is not a form of
being fair to the other developers. I have to pay my bills even though there
might be other people who don't pay theirs.
> New leadership for KDE 3.1 is needed.
I'm sorry, but you again misunderstood "release coordinator" == "KDE
leader". There is no such thing as "KDE leader of the day".
> The KDE releases are the legacy of the entire KDE community, and
> making sure those releases are good is the responsibility of every
> developer and tester. This requires that all developers, regardless
> of their social status, obey the written and unwritten rules of the
> KDE development community. A mistake by a well-known developer can
> break the release as badly as a patch from a novice, and the rules
> were agreed upon with this fact in mind. Only by keeping the written
> and unwritten agreements can all KDE developers and users continue to
> enjoy the success they enjoy now
I'm very happy that we agree on that. So lets please try to accomodate in
this way, instead of fighting each other for no apparent reason.
Dirk
