[kde-linux] KDE 3 Beta

[James Richard Tyrer]

Long blog from a somewhat old (59) engineer.

John Layt wrote:
> On Saturday 27 October 2007, Ben Kevan wrote:
>> This IS a _BETA_ release. Are you not sure the true meaning of a 
>> Beta release? On another note does anyone know if RC was tagged for
>>  release on the 30th?
> 
> It's tagged, but looks to now be called Beta 4, with the Dev Platform
>  release at RC1 instead of final release.  We'll keep rolling out 
> Beta's until it's ready for an RC.  That's KDE's traditional 
> labelling.

Sounds good to me.

<SNIP>

> The sole area of contention is the Plasma Desktop where the core 
> plasma library stuff is beta but is missing some of the user visable 
> stuff which will come quickly now thanks to the stable and powerful 
> set of libs.  Makes sense really, you don't start putting on the roof
>  and painting the house before you lay your foundations and build the
>  walls.

Yes, but ... (TM).  Using your analogy, you don't say that the house is
ready till you put on the roof and paint it.  I agree that much of KDE4
is Beta, but I wouldn't go so far as saying that the only part that
isn't ready for Beta is Plasma.  IIRC, I tried to use KWrite and it
crashed on opening -- so some of it is still Alpha.

> A myth we need to dispel is that come 4.0 everything will be perfect,
>  everything will be shiny new, everything will be finished.

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

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

> Release Early, Release Often: 4.0 is a base on which we will continue
>  to build.  There's a lot of stuff that won't make it until 4.1, 
> there's stuff that won't even make it until 4.2, there's outside apps
>  that will never be ported.  We don't wait around for everything to
> be done or we'd never get a release out.

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.

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.

-- 
JRT