KDE 3.2 release cycle

[Daniel Stone]

On Mon, May 12, 2003 at 09:29:05AM +0200, Stephan Binner wrote:
> On Sunday 11 May 2003 20:45, Stephan Kulow wrote:
> > To my counting, there are ~2300 _confirmed_ bugs known to KDE. If you can 
> 
> From which are 470 due to khtml/kjs (no problem there to confirm much more 
> with some work, and expect that growing) and 390 are for products not part of 
> KDE release cycle atm (KOffice, KDevelop, CDRs, Boson, KBear, ...). Your bug
> count based release schedule ("release when only 1000 confirmed bugs left")
> is totally unrealistic. And btw, nothing prevented three KDE 3.1.x releases 
> with the current amount of open critical and grave bugs. You have to release.
> 
> Either switch to a time-based or feature-based release-schedule now.

I'm sorry, but this is something I cannot accept. If we start shipping
releases based on time/features, then we're going to end up with
something buggy. I'm sure most users would rather have something very
nice that works, rather than something that's very very shiny and
jam-packed full of eyecandy, that segfaults whenever you click on "Lock
Desktop"[1].

We have a responsibility to our users. There's a place for "get all the
features and eye candy you want, but this edge bleeds". It's called CVS.
We already have excellent infrastructure[2] for this, so I don't see the
need to turn releases into a second CVS stream.

To me, when I see kdelibs-x.x.x.tar.bz2, that says to me, "Ah, a release.
Tested. Stable. Works". It doesn't convey to me, "Ah. Shiny. Immature. I
gotta get me some of that". If we start releasing based on
time/features, not stability, I can guarantee you that we will start
losing users. The people who are that hellbent on shiny new stuff will
grab CVS anyway. Others will just live with it.

And you're ignoring another aspect: packagers.

Here is the reason why my life has been hell for a while:
daniel at nanasawa:~/debian/xfree86-svn/people/daniel/debian/patches% ls -l * | wc -l && wc -l * | tail -1
    105
  34998 total

Now, there's a serious disincentive to package something. I'm not
inferring that KDE will turn into something that requires 35,000 lines
of patches (the count was 51k at one point) in its packages, but for
every serious bug you add, you're forcing patches upon the packagers,
and  please take my word as an ex-KDE maintainer, that it's really,
incredibly unpleasant to deal with.

The other option, of course, is more frequent releases. But if we go to
KDE 3.2.17, and it's still buggy and woefully unstable, what's the
point? KDE's reputation will also go to the toilet, not only with end
users, but also with corporations (psst: kdekiosk is there for a
reason).

"The only winning move is not to play." (Or, of course, stick to
stability-based releases).

> > Beside that, I see a revised kdepim as the key feature for 3.2 and that has
> > basicly just started. An alpha release doesn't help keeping the developer's
> 
> Why 3.2? Is whole kdepim alpha state? Or only Kontact? Then move it to 3.3.

Last time I checked, kdepim was just settling down with all the
libraries, the delineation between network/pim being sorted, etc. This
was a while ago, but not that long so that you could call it mature now.

Please, let's not go down that path. That way lies insanity.

:) d

[1]: kdesktop_lock segfaults when you click on Lock Desktop, but my
checkout is old. Still, it's a very good example of why shipping based
on time/features is utterly bogus.
[2]: Tags, branches, separate trees ... what more can you ask for?

-- 
Daniel Stone 	     <daniel at raging.dropbear.id.au>             <dstone at kde.org>
KDE: Konquering a desktop near you - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030512/074c9656/attachment.sig>