KDE 3.2 release cycle

[Daniel Stone]

On Mon, May 12, 2003 at 12:26:27PM +0200, Stephan Binner wrote:
> You seem to wrongly assume that "time-based" means the actual release date and 
> therefore no more beta/RC releases if there are too many errors? Then you're 
> wrong. I mean the date of the feature freeze: Add only the features/programs
> which are ready at a given feature freeze date (that's like the last releases
> were managed). "Feature based" in opposite would mean to define the features
> that have to be in and then delay (endlessly) the freeze until all are there.

"Time-based" still isn't stability-based. I'm all for letting the
release date slip if it means we get a better-rounded release. I
personally think it should be up to the RM's discretion. If the RM does
a bad job, the developers will complain, and either he will learn, or
there will be a new RM - it doesn't get much more simple than that.

Obviously the lack of any publicly-raised objections indicates some
level of developer faith in the RM; are there any objections anyone has
now in the RM's ability that weren't raised at the time? If there are,
I'd like to know, as the RM is an absolutely crucial position for any
project.

-- 
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/59e4c457/attachment.sig>