[kde-linux] KDE 3 Beta

James Richard Tyrer tyrerj at acm.org
Sun Oct 28 17:15:14 UTC 2007


Anne Wilson wrote:
> On Saturday 27 October 2007 12:22:01 James Richard Tyrer wrote:
>> Long blog from a somewhat old (59) engineer.
>>
> Short reply from an even older user :-)
>> The problem which I have observed in the KDE development methodology is
>> that the product is NEVER finished -- it doesn't matter if it is 4.0.0,
>> 4.1.0 or 4.2.0, it still won't be any closer to 100%.
>>
> I've never yet done anything that I thought was perfect.  There is always some 
> improvement to be made.

I agree 100%.  The question is how functional something should be before 
it is included in a stable release for the first time.

>>> That's not how open source works, that's not how KDE works.  This is
>>> not Vista or Leopard where a box ships and sits on the shelf largely
>>> unchanged for 5 years bar the odd SP or security patch.
>> I take issue with that.  KDE had grown up as it were and many people use
>> it for production environments.  If we are going to release something
>> which isn't finished, we should indicate this (like KDE4-preview).
>>
> I've been using computers since 1981, and PCs since 1987.  One thing I learned 
> early is that you never put a x.0 release onto a production machine.

Yes, that is good advice.  But how nice it would be if it weren't that way.

>> It isn't a matter of waiting around for everything to be done.  What we
>> need to do is only release the stuff which is done in our stable
>> releases.  Early KDE-3 releases contained stuff which clearly wasn't
>> ready for prime time and this reflects negatively on the reputation of
>> the KDE project.  Yes, the stable 4.0.0 release is going to have bugs,
>> but stuff that simply doesn't work is more than just a bug and should be
>> treated differently.
>>
> Is it possible to test everything completely without user experience?

No, that is why unstable versions and Betas are released for interested 
users to test.

>> Other projects have adopted a two track approach where there is an
>> unstable branch (or really it is Trunk) and there is a stable release
>> branch.  Stuff is developed in Trunk and then migrated to the Stable
>> branch ONLY when it meets QA standards.  Or, this can be reversed where
>> Trunk is the stable release and new stuff is developed outside of Trunk
>> and then added ONLY when it meets QA standards (IIUC the Linux Kernel is
>> done this way).
>>
>> There are other methodologies which could probably accomplish the same
>> ends.
>>
>> We can continue to and new stuff, but there needs to be some method to
>> ensure that we deliver a commercially viable (stable) product.  Other
>> projects have figured out how to do this, we need to do the same.
> 
> KDE 3 will not disappear overnight, I'm sure, so the stable environment will 
> be there for everyone who needs it.  Personally I shall be choosing carefully 
> where I install KDE 4.

Unfortunately, as I have stated, KDE 3.5.8 isn't really that stable. 
The reason for this is that new and unstable stuff has been added to it. 
  It also has regressions from previous 3.x.y versions which have not 
been fixed.

Perhaps you miss my point, or perhaps I wasn't clear.  I have no 
objection to any of the development work that is being done and I do not 
want any of it changed.  What I do think is that somehow we need to also 
release a more stable product that is of commercial production quality. 
  There are companies and governments which rely on our DeskTop and we 
need to provide them with a high quality product.  I see a simple way to 
do this: the stable release should not have new stuff added to it until 
the new stuff meets quality standards.  Our current development 
methodology makes this impossible.

-- 
JRT



More information about the kde-linux mailing list