Re: GNUstep core release

[Fred Kiefer]

Am 13.05.2015 um 08:09 schrieb Richard Frith-Macdonald <address@hidden>:

> On 12 May 2015, at 22:35, Riccardo Mottola <address@hidden> wrote:
>> 
>> Fred Kiefer wrote:
>>> Richard and I are planing to do a shared release of the GNUstep core 
>>> modules (at least base, gui, back, maybe make as well) on May 15th. Could 
>>> you all please test the current code and report any regressions. Up to this 
>>> date we should all stop to add new features and restrict us to important 
>>> bug fixes.
>> 
>> I would like to see certain bugs fixed or at least analyzed before a release

It would be great to resolve all these, but none of it is a show stopper. The 
release should be done regardless of the state of these bugs.

>> 
>> 1)  bug #45032: [base] Bundle not correctly returned for Class in Framework
>> which I'd classify  as a blocker
> 
> As long as this is ony on your Solaris system, it's hard to see how to 
> address it (unless you can provide a fix).
> Is it a regression, or a long term problem?

As far as I know this is no regression. It seems to be related to NSBundle 
having a wrong view of the file system layout. Sometimes only the first number 
from the version gets used.
Most likely this only affects Solaris as we use different mechanisms on other 
systems to get the classes when loading a framework. A simple solution could be 
to check for different directories, removing the parts of the version number 
one by one.

>> 2) bug #45081: gui and back do not pick up compiler setting
>> Confirm my fix and agree if have a warning or error like now
> 
> I think your fix looks fine, and for the case where an environment variable 
> is used explicitly, I think a warning is sufficient (I'm a power user and am 
> OK with the error; since it only takes 30 seconds to reconfigure/reinstall 
> gnustep-make for a new compiler, but if it really bugs someone else then I 
> don't mind it being a warnign instead).

I would prefer to have this as a warning in gui and back. On the other hand I 
personally never had the need to use a special compiler for building these.
> 
>> 3) bug #43454: Problem with Continuous Spell Checking
>> How serious is this?
> 
> I'm not familiar with that one ... will try to take a look at it today.

This issue is annoying but hard to resolve. Waiting for this might delay the 
release indefinitely. Do we really want to do this?
There are two issues here. One being that the layout system isn't thread safe. 
To change this requires a lot of rework. The other is, why are we getting 
there? To reproduce the problem I had to write illegal code. Which part of gui 
is accessing the layout system from a secondary thread? It might be easier to 
address this.
> 
>> 4) bug #29730: Build attempt when typing 'make distclean' twice
> 
> I'll definitely get that into base.

This is a rather old issue, it would be nice to have it fixed, but again not 
needed for a release.