gnugo-devel
[Top][All Lists]
Advanced

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

[gnugo-devel] The late phase of the release cycle


From: Daniel Bump
Subject: [gnugo-devel] The late phase of the release cycle
Date: Fri, 1 Mar 2002 22:04:31 -0800

Recent speedups make it possible for us to plan on releasing
GNU Go 3.2. I'm writing a few words about the late phase of
the release cycle. 

I don't expect the 3.2 late cycle to be nearly as
protracted as the 3.0 one, which was complicated by the
fact that we were also preparing for tournament play.

Before the 2.4 and especially the 2.6 releases we forked
the code. I hope to avoid that this time.

So far we've done four stable releases of GNU Go, 2.0, 2.4,
2.6 and 3.0.  Our development model is patterned after the
Linux kernel, not only in our adoption of Linus-style
odd/even revision numbers, but also in the preparation for
a stable release. As the stable release approaches we 
become increasingly conservative in what we accept. After
a while (say after the big patch Gunnar is working on)
we get to a feature freeze in which we don't want to add
new features, especially ones that could break something,

During this phase we want portability patches, bug fixes,
speed enhancements, and conservative tuning. Testing is
important. Experimental stuff can wait for a month or
so. Particularly, anything that's likely to break
something should not be submitted unless there's a very
good reason for it.

Right now I think tuning is still important, though owl
tuning should be avoided as I will explain. We may need
some tuning because the recently made standard experimental
influence code may have broken some tunings.

Consider the recent game gnugo-3.1.26-journeyman-200203020154.sgf,
available at http://www.lysator.liu.se/~gunnar/gnugo/nngs/.
At moves 20 and 24 GNU makes knight's moves that are unsupported
by the surrounding position. Probably 18 and 20 should both
be at J5 or H3, and 24 and 28 are also good moves to tune at.
I think it is safe to say that GNU Go 3.1.27 is stronger in the
late middle game than in the early middle game and late fuseki.

Tuning that can be done by EJ patterns is good. Tuning
that can have side effects is bad.

Owl tuning, by contrast is bad at this time for two reasons.
First, adding owl patterns slows us down, and we don't want
to slow the engine at this time. Second, owl tuning can have
side effects, sometimes serious ones, that aren't noticed
right away.

About testing, right now I'm running 100 game series on
2 machines. This will turn up crashes (or show that the
program doesn't crash) and statistical deviations could 
indicate a broke release. Towards the final week or so
before the release we will test build on various
platforms.

Anyone that wants to submit documentation is invited
to do so in ASCII format if that is more convenient
than writing Texinfo.

Dan



reply via email to

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