gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Fred Kiefer
Subject: Re: Code/Feature freeze starting next friday...
Date: Sat, 10 Apr 2010 10:17:49 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.8) Gecko/20100228 SUSE/3.0.3-1.1.1 Thunderbird/3.0.3

Am 10.04.2010 00:26, schrieb David Chisnall:
> On 9 Apr 2010, at 22:37, Fred Kiefer wrote:
>> 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...

Because these two give completely different results in some cases?
I just tried gdl2 and could not make sense out of the report I got from
svn log. Just think of me as an old fashioned person :-)

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

Could you please send me a full report of these warnings? I didn't get
around to install clang on my computer up to now.


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

Fully agree here.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]