On 1/10/08, William Harold Newman <william.newman@...> wrote:
> clothes and the upside is negligible. And I'm not even sure the signal
> of extra hassle can easily be distinguished from the usual hassle
> On the other hand, the usual hassle noise level is high enough that it
> could conceal a fairly large signal, and I generally tend to weight
> hassle fairly heavily.
Keeping extra hassle down to acceptable levels is definitely a priority
for me. Unless a process is obviously too heavy/complex/long, the best
way to gauge it is probably to try it out...
> Also, one thing that makes me unenthusiastic about direct
> participation in an especially-reliable beta process is that to the
> extent that the project is useful relative to the main development
> line, it seems that it must involve a stream of serious judgment calls
> about how much change to include in the solid version. Of course, all
I don't know how to make sure we make good judgement calls there,
but unless people with experience on that front appear out of the
woodwork, then I suspect "trial and error" is not the worst starting
...all in all, I judge the likelihood of any maintenance branch of
SBCL being "stabler" over N months then the corresponding sequence of
montly releases to be more then fair: getting even some bugfixes without
API changes seems like a huge step forward on the "stable base" front. :)
Perhaps using patches for maintenance makes this slightly easier: bad
patches can be revoked, etc.
> One possibility (which I seem to remember I've mentioned on the list
> before, but which I'm not sure how to search for conveniently) is that
> such a solid beta release process could be largely decoupled from the
> main development and release process. As long as it is even minimally
> culturally compatible with the main branch, a solid beta branch could
> share space on key web pages (like SourceForge File Releases), and I'm
> not sure it would need much else. And besides the usual MORE WNEWMAN
> "COULDN'T THIS BE DECOUPLED?" CHANT reflex, doing it decoupled might
> have actual advantages:
> * It's a commonplace among people serious about reliability and quality
> (not just in software) that it can be important to have testing and
> reliability judgments made by people not too directly invested in
> the production.
> * If I'm right that it's harder to get a single technical consensus
> for reliability tradeoffs than for generally developing the best
> we can, then being decoupled could have an advantage of letting the
> people who are primarily interested in the ordinary development go
> on with what their business almost no matter what. (There are limits:
> if it gets to the point where competing reliability branch teams win
> bakeoffs by sabotaging each other's AC power, we'll probably be
I'm all for this if maintenance personnel appears... Maybe I'm not
looking in the right places, but I see little indication of there
being people interested focusing on this -- and without such people
the decoupling just cannot happen.
...but even without a separate pool of QA & maintenance people we
can _try_ to make point releases more reliable then monthlies.
> so if I'm wrong and there *is* a consensus on how we should be
> numbering releases, I'll probably be happy to go along.
I don't think there is a huge consensus, but I think we can stay
within established tradition easy enough.
Here's a proposal.
* Let's do 1.1 in a month or few. (Say, on the March-May axis?)
I think it would be fine for any given developer to say that they
want feature/fix X to be in the release, as long as they are willing
to see to it in the above timeframe. Beyond that, we already have
a great deal of stuff to release, so I don't think there is need
for a list of todos.
* When it's the time, call the version we would normally freeze
1.pre1.0, push out snapshots, and ask users to give it hell.
As reports come in, fix bugs (versions 1.pre1.X.) After a week of
testing, if necessary, push out a new snapshot.
Repeat till happy -- maybe the commits after the first snapshot
are so conservative that we don't want to do a second, and end
up tagging what would have been the second snapshot as 220.127.116.11 --
or maybe we'll do a dozen snapshots. As long as the development
is not completely arrested (just restricted to fixes), I don't
think that should matter greatly.
(The aim here is to find a balance between a long beta and
keeping development live. I'm not married to this way of doing
things, so "I agree in principle, but disagree on the details"
is a valid and valuable answer.)
* After the release, the next month uses the 1.1.0.X version numbers
* IF we figure out what a point-release patch system should look like,
provide patches for 1.1 using it when we can and dare.
How's that sound?