<br><br><div class="gmail_quote">On Sun, Jan 17, 2010 at 2:51 AM, Andreas Pakulat <span dir="ltr"><<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 17.01.10 00:56:47, Aleix Pol wrote:<br>
> On Sat, Jan 16, 2010 at 11:12 PM, Andreas Pakulat <<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>> wrote:<br>
</div><div class="im">> > Do you have something that you want to implement? So far it seems nobody<br>
> > really has any feature he thinks needs to be done for 4.0. And making it<br>
> > official that we're in freeze means we have all the good reasons to<br>
> > concentrate on bugfixing instead of playing around on a new feature<br>
> > which might not even be finished for 4.0.<br>
> ><br>
> > Well there's a leap between adding features and being freezed. It's kind of<br>
> hard to fix stuff when you can't change strings, for example.<br>
<br>
</div>Not at all, there are tons of bugs that don't need change of strings.<br>
But as I said, we can probably delay the string freeze a bit.<br></blockquote><div><br>But we want to do free and liberal bugfixing during the meeting :)<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> Plus if we came up with any feature why not add it?<br>
<br>
</div>Because we actually want to release KDevelop 4.0. We need to stop adding<br>
features to do that and concentrate on getting the outstanding bugs<br>
fixed.<br>
<div class="im"><br>
> > > We don't have a final release date, do we?<br>
> ><br>
> > David suggested end of march back when we decided to slip KDE 4.4<br>
> > release date and nobody objected.<br>
> ><br>
> How much time do we want to be freezed (in RC I assume) until we released?<br>
> We could build a release schedule from the end of the meeting.<br>
<br>
</div>Well, we had the option of having 2 months of freeze and it was decided<br>
thats not enough. As the amount of big changes seems indeed to slowly<br>
drop I think doing a 2 month freeze would be enough then. And that means<br>
freezing before the meeting, unless we want to delay the release yet<br>
another month.<br>
<br>
So far in all the mails where I've asked nobody had any problems<br>
releasing end of march (which in turn means freezing start of Feb at the<br>
latest). We really need to find some conclusion on the dates and then<br>
stop changing things around just because someone had a good idea for X<br>
or Y. Else we can just stop worrying alltogether and not release at all.<br>
<br>
Andreas<br>
<br>
--<br>
A few hours grace before the madness begins again.<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br>Well, the meeting is in mid february, we could release in early april. Having RC's from right after the meeting is over.<br>I wonder if more people will try kdevelop once we're freezed though. <br>
<br>Aleix<br>