Restricted feature-unfreeze for 3.5.3

David Faure faure at kde.org
Mon Mar 20 08:06:49 GMT 2006


On Saturday 18 March 2006 21:50, Aaron J. Seigo wrote:
> On Saturday 18 March 2006 12:06, Albert Astals Cid wrote:
> > A Dissabte 18 Març 2006 19:45, Aaron J. Seigo va escriure:
> > > what does this nice patch do?
> >
> > Implements 20th most wanted feature on our bugzilla (1st about kpdf) with
> > votes from 54 people
> > http://bugs.kde.org/show_bug.cgi?id=99352
> 
> for others: it's about being able to change the orientation of a pdf (e.g. 
> landscape -> portrait).
> 
> it's hard to say without actually seeing the patch, but i'm all for polishing 
> 3.5 without spending too much time doing so as it keeps progress visible even 
> if in a rather trivial fashion. i remember how 1.1.2 just sat there for the 
> longest time while kde2 was hot on the burner in development; a 1.1.3 
> would've been nice ;)
> 
> i'm just hoping we don't turn too much energy onto 3.5.x or threaten it's 
> stability by trying to "cheat" a 3.6 release by stuffing crap into 3.5. 
> feature additions open up the possibility for bugs, require forward porting 
> (in a good world, anyways =), possible documentation changes, etc, etc... 
> 
> > > personally, i'd rather see this happen on a case-by-case basis with a
> > > conservative approach favouring fixes and non-feature-changing
> > > improvements over feature additions rather than a full on unfreeze which
> > > would just be a pandora's box waiting to happen.
> >
> > I agree here.
> 
> obviously i'm cool with this compromise.. what about others, particularly TWG 
> members?

That's basically the idea we had, too. Allowing a few feature-freeze-breaking commits
on a case by case basis, particularly for features that have *already* been developed
and tested. For instance Lubos's startup performance patches, tested in SUSE.
The above PDF addition sounds ok too since the patch already exists.
To keep this clear: we do NOT want anyone to start developing 3.5.x features
right now. We only want to allow existing (and tested!) code to be committed.
If anyone plans on developing any feature now, do it in trunk.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).





More information about the kde-core-devel mailing list