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

List:       kde-devel
Subject:    Re: KDE Development Policy
From:       Christopher Molnar <molnar () kde ! org>
Date:       2002-03-09 14:18:33
[Download RAW message or body]

While I hesitate to reply to this it sort of pissed me off so that I will 
anyways......

As other people are sure to do I am going to put some comments and cut out a 
lot of the quoted reply....

On Saturday 09 March 2002 02:48 am, Neil Stevens wrote:
> KDE 3 has been mismanaged by the KDE developers.  The standards and
> practices of the KDE development community, those held in the
> successful KDE 2 series, have been abandoned.  The result has been a
> failed release candidate, growing developer discontent.  The future,
> though uncertain, is likely to bring the conclusion that KDE 3.0 was
> the highest profile KDE failure to date.

Hmmmm... KDE 3 has not been released yet. How can you possibly know it is a 
failure?

>
> When the evidence is brought together, the current state of KDE 3.0's
> development is easy to call a failure.  Release Candidate 1 and
> current cvs are plagued with problems including:

I compile kde nightly. The only problem I see is failing packages in 
kdenonbeta which is expected.

>
> 1) Packages missing from the release entirely (1)

Usually packages missing are ones that are not stable or have a legal issue 
(like trademark issues) not to include.

> 2) Rampant compile problems

Where? I don't see any.

> 3) Last-minute changes to build requirements that cannot be met by
> many developers without an operating system upgrade (2)

So update or continue to use KDE 2. Nobody is twisting your arm to move up in 
the world. It is a risk you take. You know that you have to upgrade certain 
things to use KDE3. You as a user have that choice. 

> 4) Many outstanding bugs (3)

Oh, come on. I know you are in the QA world and if you have had any training 
in that field you know that a 100% bug free release is an extremely dangerous 
and impossible goal to get to. I would like to suggest a book for you to 
read. It is "Software Quality - Analysis and Guidelines for Success" it is 
written by Caper Jones and it has an ISBN number of 1-85032-867-6. It may 
help you over some of your missconceptions.

>
> While these problems are bad enough, they in turn throw up further
> obstacles to a stable release:
>
> 1) When users and developers cannot build KDE, they cannot test KDE

Wrong, KDE can be built. I build it nightly and if the off chance that a 
portion doesn't compile I wait 20 minutes, cvs update and then it builds 
again. If anyone wants to use my builds, all they have to do is ask. I will 
happilly make my /OPT/KDE3 directory rsyncable so that people can use my 
builds. Of course you need to be running Suse 7.3 to make this work right.

> 2) When developers are locked out of KDE builds, they cannot
> contribute fixes.

Locked out? How..... I have CVS access - don't use it much but if I need to 
contribute a fix or something I know I can - and in the past have. Right now 
if I wanted to fix something I would follow the guidlines post the patch. I 
would probably have an answer in 20-30 minutes and then I would probably 
commit if the patch was OK. I do not see how that is called being locked out.

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

Bullshit. You mention the growing number of bugs. That is in direct conflict 
with this statement. How can you possible know the number of users testing an 
open source internet product? This is an impossibility to calculate. This is 
not a closed source, corporate world you are talking about. Most of the same 
rules do not apply.

>
> 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.  In
> cases like this, the whims of a few dictate large change for the
> masses.

And did libtool break anything? No. So get over it. The few that may dictate 
though are the few that have written a majority of the code. I sort of think 
that this gives them the right to dictate a little. Besides, I have seen 
every one of these guys back down if someone provides evidence that what they 
are doing does NOT make sense.

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

Again, you are not in a closed corporate environment. I, like you, a month ago 
was seriously pissed off at the kaccel changes that was breaking kdelibs on 
an hourly basis, but this has solved itself and we have  a much stronger 
product now. I have come to the conclusion that this is a much better method 
of software development than adhearing to the total feeze.

My last computer related job was at MandrakeSoft, prior to that I was a 
Quality Assurance supervisor at Aetna-US Healthcare insurance company. The 
last major project there, the one that drove me basically to leave, was a 
sales and marketing application that ran $5.2 Million over budget, 4 years 
longer than it was supposed to, and had a developer turnover of close to 70% 
over those four years. Included numurous software (OS) upgrades and went to 
production over my strongest objections (rufusal to sign off) with roughly 
8000 open severity 1 bugs. It was a single application. Now, take that into 
context with what is going on in KDE. THere is a different picture.

-We are NOT in production yet with KDE3.
-We are in a SOFT FREEZE.
-We are not releasing anything with CLOSE to 8000 open severity 1 bugs.
-If you take a close look at the bugs you will find a lot of them have been 
fixed.  (how about volunteering to do a cleanup).
-Development is on-going
-We are not over budget, hell... do we even have aa budget ?

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

It hasn't broken anything and what you may not have seen in other releases was 
the amount of patching that all the distributions have to do to make KDE2 
work well. Take a look sometime at the source RPM for Mandrake's version of 
KDE2.2 and the number of patches in that. I think this is a far better 
aproach. Yes, it makes me VERY nervous as I am still stuck in some of the QA 
from the corporate world. Yes, having a BC day last night may not have been 
the best idea, but I got a perfect compile and am very happy with it. I may 
even later today try to fix something in knode that is anoying me.

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

I do think kde3 should possibly be delayed by  a few weeks, but that is my 2 
cents worth and it realy doesn't matter to me because I build from CVS always 
and never use a release version.

>
> The leader's role is to gather the views of the entire KDE development
> community, summarize them in the form of release plans, enforcing the
> plan when it is ignored, and updating the plan when it falls behind.
> 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, and KDE 3.1 needs a release
> coordinator who well help the entire KDE community achieve that.
>
> P.S. Neil Stevens volunteers to take the role described in the last
> paragraph.

OK, You had me agreeing until this last portion. Neil, how much code have you 
actually commited to the cvs? There is no way that a release coordinator can 
take on the role unless you have the ability to know all the apps, code, 
source, cvs inside and out. How could you judge the quality, and the 
redieness.  after reading the last pharagraph and then your volunteering, I 
am wondering what's in this for you - sort of sounds like a job posting to 
me.

Along with that what you are suggesting will slow development, drive away 
development volunteers and needlessly piss people off. So why do it?

This message is my own oppinion and others may not share it, but I am sure you 
will be hearing from them anyways.

-Chris

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]