To freeze or not to freeze?

Andreas Pakulat apaku at gmx.de
Sat Jan 16 22:12:46 UTC 2010


On 16.01.10 22:49:35, Aleix Pol wrote:
> On Sat, Jan 16, 2010 at 10:43 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> 
> > On 16.01.10 22:25:05, Milian Wolff wrote:
> > > David Nolden, 16.01.2010:
> > > > Am Samstag 16 Januar 2010 20:57:14 schrieb Andreas Pakulat:
> > > > > So apparently people are happy with freezing. That would mean
> > complete
> > > > > feature freeze in a bit above 2 weeks (if my calendar is correct).
> > I'll
> > > > > announce it on monday on the list (unless someone objects)
> > > >
> > > > A total feature freeze in 2 weeks is ok, but only if UI tweaks, like
> > making
> > > > stuff more consistent or renaming it, are not put into the "feature"
> > > > category.
> > >
> > > Yes, a string freeze should not be started with this feature freeze imo,
> > there
> > > are potentially many places where one would want to clarify or add
> > things.
> >
> > We need to give translators time to actually finish the translations. So
> > while we can probably delay the string freeze a bit, we certainly need
> > to give them more than a month to finalize translations - IMHO.
> >
> > > > Apart from that, there is 2 important mini-features I think that are
> > still
> > > > missing:
> > > > - Path-specific source-formatter settings (you wanted to work on it
> > this
> > > > weekend, so might not be a problem)
> > > > - A blacklist for project-items, so we can finally get the "*~",
> > ".bak",
> > > > ".rej" etc. crap out of quickopen and the project tree.
> > >
> > > One would probably just have to port the stuff I wrote for the
> > genericmanager
> > > to a base class and reuse it where appropriate.
> >
> > There's no base class, IMHO would be good just as a utility class that
> > can filter a given list of urls (or strings maybe) based on some config
> > from the project. And of course the kcm to configure this.
> 
> I think that while we are on the sprint it has to be possible to add new
> features. Being pre-freeze or for the next version. We don't want to be so
> much locked up.

Do you have something that you want to implement? So far it seems nobody
really has any feature he thinks needs to be done for 4.0. And making it
official that we're in freeze means we have all the good reasons to
concentrate on bugfixing instead of playing around on a new feature
which might not even be finished for 4.0.

> We don't have a final release date, do we?

David suggested end of march back when we decided to slip KDE 4.4
release date and nobody objected.

Andreas

-- 
You have a reputation for being thoroughly reliable and trustworthy.
A pity that it's totally undeserved.




More information about the KDevelop-devel mailing list