KDE 3.2 release cycle

[Daniel Stone]

On Mon, May 12, 2003 at 02:58:18AM -0700, Neil Stevens wrote:
> On Monday May 12, 2003 01:52, Stephan Kulow wrote:
> > On Monday 12 May 2003 09:29, Stephan Binner wrote:
> > > Either switch to a time-based or feature-based release-schedule now.
> >
> > Any reason why? I still think that KDE is in a state where features
> > don't bring us further, but all these little bugs and misfeatures are
> > those that are missing to perfection. So while a time based schedule
> > makes sense as soon as you fixed a good share of bugs, I don't want to
> > see a KDE 3.2 that is released just because some months passed.
> 
> So, why will delaying get more bugs fixed?  Do you think that developers 
> want to fix them, but just don't have time?  Do you think that developers 
> haven't wanted to, but will to get the release out?

If you say "no new features for you, just fix bugs", then bugs will get
fixed instead of features added; it's that simple.

I think that your latter suggestion is right. Let's face it - hacking on
new features is far more sexy than fixing bugs. It's grunt work. Given
the choice, no-one will pick bugs. But, if you say, "Look guys, the
features rock, great work, but it's time to eliminate the segfaults and
other bugs", people will grudgingly do it, especially if a freeze is
imposed.

Conferences are also handy for this.

If you want to dispute me, I suggest you go back and look at previous
releases, where exactly what I've just described has happened. It's how
releases work everywhere. Debian, KDE, GNOME, FreeBSD, NetBSD, OpenBSD
... it's just how it happens, it's a fundamental fact. If you want to
dispute the wetness of water, feel free, buuttt ...

> There's a big difference here.  If developers don't want to fix bugs, then 
> delaying won't get the bugs fixed.  The developers will just keep adding 
> features, making stability gradually worse, for that's what separate 
> releases are for.  Or if a feature freeze is imposed, then development 
> will just move off of HEAD.  You can't force volunteers to do what they 
> don't want to do.

No, but you can goad them towards what they'd prefer doing less, and it
will be done. Debian, KDE, GNOME, and every other large project known to
man has already proven this.

> I think some sort of compromise is needed.  Go with stability-based 
> releases, but with a default time if the stability goal isn't reached by 
> then.

So, if the goal isn't reached, we just say, "We know this release is
utter crap, because we couldn't meet our target, so we just gave up and
released this sub-standard snapshot. Caveat emptor, and enjoy KDE!"?

I'm glad this isn't what's happening.

-- 
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/765ce54f/attachment.sig>