[Top][All Lists]

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

Re: New -base release?

From: Richard Frith-Macdonald
Subject: Re: New -base release?
Date: Tue, 2 Aug 2011 19:02:49 +0100

On 2 Aug 2011, at 09:44, Fred Kiefer wrote:

> Hi David,
> you don't seem to get the point. I don't have to tell you that a change the 
> contains the word "fix" is just as likely to break something as if it doesn't 
> contain that word.
> And even if these fixes where 100% correct, we still need to make sure that 
> none of the other changes has any effect outside the proper target 
> environment.

Yes ... very, very often fixes for a problem in one environment break things in 
other environments.

> I would suggest that we start a code freeze for GNUstep base on the next 
> weekend. This gives people some time (although rather little) to push in 
> features that they really want to see in the next release.
> Then we have two weeks of code freeze during which only changes to the test 
> are allowed, plus bug fixes that are supported by tests. NO new features 
> during that time, not even tiny ones.
> After that a release would be fine for me.

> Could we agree on that schedule? I will try to get some response from Richard 
> on this.

Sounds good, though I'm largely away on holiday this week and next  (and then 
away on a course on the last week in August).   I'm not going to be in a 
position to do much (or perhaps any) testing on that timescale.
Normally there are certain environments where we should tolerate NO test 
failures ...

The primary two, used by the vast majority of people, are:

gnu/linux built with gcc and the traditional runtime (at least 32bit and 64bit 
mswindows built with gcc and the traditional runtime (at least 32bit intel)

I generally also try to test that solaris is working (again for gcc and the 
traditional runtime) with sparc and sparc64 so we have a good test for 
big-endian systems, and also to check that a gnu/linux/gcc/trad-runtime build 
for GC works (all the new GC changes may have broken this).

And nowadays we really need to test builds with clang, new runtime, and with 
the latest gcc and the new gcc runtime, and we have two new GC variants ...

So three different compiler/runtime setups at least, various cpu architectures, 
and now four memory management schemes (trad retain/release, gc with gnu 
runtime, gc with new runtime, automated retain/release).
That's a lot to get tested ... so the timescale may not be realistic :-(

Anyway, must go ... working on a rather unreliable internet connection at my 
campsite ... I hope this email gets through.

reply via email to

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