[Chicken-hackers] Minutes of 2012-06-14 IRC meeting

[Alaric Snell-Pym]

Sorry to take a while writing these up and sending them, I got distracted!

Felix popped into #chicken and a quick meeting about the next release
occurred.

 * It was proposed that the next release come real soon now as we've
hung around too long. We feel there's known instability in the
scheduler, but fixing it will be a new project, the remaining Windows
issues don't have enough interested users to fix them, and it's been too
long since 4.7.0.

 * It was also proposed that we should stop calling them "stability
branches", which confuses users, and instead make them a new level of
point releases.

The model will be that we make a release of master whenever we think
it's ready (eg, we've fixed all the bugs we're going to fix), and call
it A.B.0 (see http://wiki.call-cc.org/release-policy for how this
happens); development then starts on the next release (which might be
A+1.0.0 or A.B+1.0, depending on how awesome it is; we can also do
interim "development snapshot releases" of A.B.1 and up whenever we feel
it's useful to do so - see http://wiki.call-cc.org/release-policy
again), but any bugs in existing functionality that arise get fixed on
master and we periodically publish an A.B.0.1 with them back-ported onto
the A.B release branch whenever it seems essential, and an A.B.0.2 when
we have some more, etc. This is basically what we do anyway, but we
confuse people by calling them stability branches and having the "-st"
suffix.

So, to clarify, as I understand it, Chicken version numbers mean:

A.B.0 (often A.B for short): Stable release

A.B.0.X: Even more stable release with bug fixes added; formerly known
as A.B.0.X-st

A.B.C: Development snapshot of work towards A.B+1 or A+1.0, with
exciting new features and new bugs. It's basically a beta!

A.B.C.X: If we deem it worthwhile, we can backport bug fixes from master
to development snapshot branches, too. Formerly known as A.B.C.X-st

Also, we discussed threads and the scheduler, which is an area of the
code we have poor confidence in. Alaric proposes to try and simplify the
scheduler by making a more functional implementation of the tricky bit,
which is deciding when to unblock threads. In effect, we need a
procedure that takes a list of blocked threads (blocked on fds or
timeouts or both), and a closure that will do the job of select(), and
returns a new list of blocked threads (hopefully smaller) and a list of
now-runnable threads. That can be used by the actual scheduler (where it
will hopefully make things clearer by separating that from the
mechanisms of context switching and interrupts), or it can be run from a
test harness with a mock select() to check it handles awkward cases
correctly.

Felix thinks he might have fixed the exceptions-in-finalizers thing, but
worries that finalizers should really run in a dedicated thread rather
than in arbitrary threads.

ABS
--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/