To freeze or not to freeze?

Andreas Pakulat apaku at gmx.de
Sun Jan 17 01:51:16 UTC 2010


On 17.01.10 00:56:47, Aleix Pol wrote:
> On Sat, Jan 16, 2010 at 11:12 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> > 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.

Not at all, there are tons of bugs that don't need change of strings.
But as I said, we can probably delay the string freeze a bit.

> Plus if we came up with any feature why not add it?

Because we actually want to release KDevelop 4.0. We need to stop adding
features to do that and concentrate on getting the outstanding bugs
fixed.

> > > 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.

Well, we had the option of having 2 months of freeze and it was decided
thats not enough. As the amount of big changes seems indeed to slowly
drop I think doing a 2 month freeze would be enough then. And that means
freezing before the meeting, unless we want to delay the release yet
another month.

So far in all the mails where I've asked nobody had any problems
releasing end of march (which in turn means freezing start of Feb at the
latest). We really need to find some conclusion on the dates and then
stop changing things around just because someone had a good idea for X
or Y. Else we can just stop worrying alltogether and not release at all.

Andreas

-- 
A few hours grace before the madness begins again.




More information about the KDevelop-devel mailing list