To freeze or not to freeze?

[Aleix Pol]

On Sat, Jan 16, 2010 at 11:12 PM, Andreas Pakulat <apaku at gmx.de> wrote:

> 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.
>
> Well there's a leap between adding features and being freezed. It's kind of
hard to fix stuff when you can't change strings, for example.
Plus if we came up with any feature why not add it?


> > 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.
>
How much time do we want to be freezed (in RC I assume) until we released?
We could build a release schedule from the end of the meeting.


> Andreas
>
> --
> You have a reputation for being thoroughly reliable and trustworthy.
> A pity that it's totally undeserved.
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100117/81c90d3f/attachment.html>