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

List:       kde-core-devel
Subject:    Re: KDE Development Policy
From:       Dirk Mueller <mueller () kde ! org>
Date:       2002-03-09 12:03:28
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]