[Top][All Lists]

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

Re: gnustep-base code freeze

From: Fred Kiefer
Subject: Re: gnustep-base code freeze
Date: Fri, 01 Apr 2011 10:53:47 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv: Gecko/20110221 SUSE/3.1.8 Thunderbird/3.1.8

On 01.04.2011 06:50, Richard Frith-Macdonald wrote:

On 24 Mar 2011, at 11:16, Nicola Pero wrote:

Can we please spend the next few days testing base but not making
any changes other than documentation and any fixes for serious
bugs (and perhaps the one number formatter bug reported by the
testsuite). I'd really like a new base release this month, and
there's not much of it left.

Sounds great. :-)

But there's a few improvement to configure for gnustep-make and
gnustep-base (to improve detecting support for ObjC exceptions and
blocks) which are pending.

Shall I go ahead and make these changes in the next day or two, or
shall we make them after this release ?

I think they are good to have, but would require another few weeks
of widespread testing in the wild before we can release them.  If
you want to release quickly, it may be too late ?

Well, we missed the end of the month deadline ... that's a pity, but
in part it's because of finding/fixing a few significant bugs which
really need more time for testing anyway (in particular the changes
for the problem David found on 64bit systems).  There's also the
issue that several of the base library tests fail on mswindows
(mostly I think that's errors in the testcases rather than errors in
base, but this needs checking), and NSRunLoop is currently broken
when using garbage collecting rather than reference counting
(irrelevant to most people, but critical to people using GC).

I guess we therefore need a couple of weeks to iron out those last
few issues, so if you can do those changes quickly it would be good
to get them in.

This doesn't sound great. I already had to tell people to stop committing changes to GNUstep gui and this must be frustrating for them. If we now prolong the code freeze and testing period indefinitely this surely will lead to random patches being committed again.

We need to define a limited time for any further changes. One more week would be fine, but I would stop after that and release what is there. Given of course that Adam has time to do a release by then.

I am willing to look into these MS Window issues myself over the weekend.

reply via email to

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