Re: Code/Feature freeze starting next friday...

[David Chisnall]

On 9 Apr 2010, at 22:37, Fred Kiefer wrote:

> Am 09.04.2010 20:06, schrieb Gregory Casamento:
>> I propose that we freeze the code to all new features on the trunk
>> before the release starting next friday (4/17).   The freeze should be
>> in place for a week or two so that we can find bugs and correct them
>> prior to the release planned for either this month or early next
>> month.
> 
> Looking over the ChangeLog files of base and gui (Yes, another good use
> of these files that would be annoying to be replaced with an SVN
> command),

Because 'svn log | more' is much more effort to type than 'more ChangeLog'?  
Not entirely sure I understand that logic...

> I would say that we are in feature freeze mode for almost two
> weeks now for both libraries.
> OK, my header changes could and did break applications including these
> headers, but tit really wasn't a functionality change.

I think I'm inclined to agree.  I thought we were already in feature freeze 
mode, so I've been holding off breaking things (which, as you know, is my 
hobby).  Refactoring the run loop code is next on my TODO list, and I want to 
do that just after a release so I have lots of time to fix it before real 
people try using the code.

> From my point of view we could aim at an earlier release date. The
> issues I expect with the new release aren't that much in the core code
> itself, but all the applications using GNUstep should be checked to see
> how much adjustment is needed there.

I think the important thing is not the feature freeze, so much as the 
pre-release testing.  Clang flags quite a few warnings when compiling -gui at 
the moment, and it's worth spending a little time before the release checking 
how many of these are real problems.  

A few come from our protocols not adopting the NSObject protocol, and some come 
from sending messages to forward-declared classes.  There are quite a few 
instances where objects are passed into format strings with %x, which is only 
correct on ILP32 or ILP64 platforms, not on LP64 or LLP64 (e.g. Linux or 
Windows on x86-64).  These should be %p.  There was one case where an integer 
was passed as %@, but I think this is fixed now.  

There are also a few if statements with empty bodies, for example 
GSToolbarView.m lines 346 and 363.  Looking at the code, these appear to be 
bugs, which should be fixed.  

There are lots of warnings where TEST_RETAIN() is used and the result is 
ignored.  These are important, because they can lead to subtle bugs where an 
object returns something other than self from -retain.

There are also some strange problems with RETAIN(super) and RELEASE(super).  
For some reason, the fact that these expand to [(super) retain] and not [super 
retain] breaks clang.  This is a clang bug, but it would be nice if we could 
compile cleanly anyway.  It seems that these macros are superfluous anyway, 
because, if we're in a -retain method (which is the only place that they're 
used), we are obviously running in a mode when -retain and -release messages 
should be sent...

> Or are there any important feature changes pending, I am not aware of,
> that should go in until next Friday?

I'm happy to start the feature freeze today.  If anyone has big blobs of 
uncommitted code, we probably don't want them dumping it into the repository 
just before we start pre-release testing...

David

-- Sent from my IBM 1620