Re: [Sbcl-devel] pushing back release YA day (Re: possible sblc bug)

[<wil...@ai...>]

On Tue, Nov 28, 2006 at 03:00:23PM -0800, Cyrus Harmon wrote:
> 
> On Nov 28, 2006, at 2:38 PM, Juho Snellman wrote:
> > Brian Mastenbrook <br...@ma...> writes:
> >> Apologies for jumping in on something I haven't really been  
> >> helping out
> >> on. I've been seeing a lot of patches during the freeze and  
> >> leading up
> >> to the ship date, and if I were to put my programmer hat aside and  
> >> think
> >> like a project manager for a minute, I'd say this was a warning sign.
> >> Why not push 1.0 out another week or two and see if the freeze stays
> >> frozen?
> >
> > Please, let's not do that. Having multi-week freezes for a project
> > with a one month release cycle doesn't seem sensible. If it turns out
> > that there's something wrong with 1.0, it'll get fixed next month.
> 
> I beg to differ. I think that strategy makes sense for our usual  
> releases, but that there are a greater-than-usual number of folks who  
> will take version 1.0 and wait until another significant release  
> before they pick up another release. If we're going to bother to bump  
> the major version number, we should consider altering our release  
> engineering strategy a bit to suit the release. A multi-week freeze  
> makes sense to me if it means that we have a better chance of getting  
> the 1.0 release "right".
> 
> While I certainly don't want to see post-1.0 development on hold any  
> more than necessary, I see no reason to rush 1.0 out the door.

The goal of getting 1.0 so correct that people can just grab it and go
is desirable, but truly I'm not sure how to achieve it.

Of course, I'm talking about the problem of getting 1.0 qualitatively
more correct than 0.9.x; if the 0.9.x releases are sufficiently
correct that they can be considered grab-and-go-ready, then of course
I have a strategy for that: do like before and just try to avoid stage
fright.:-)

If I think about some significant free software projects that I've
used, it seems to me that most of them would like to make their
round-numbered releases qualitatively more reliable if they could ...
but in practice they aren't terribly successful at it.
  * Linux? For many things, any w.x.y.z release is good enough, you
    needn't wait for a round number. I haven't worried about things
    where it makes a difference for some years, but when I did have to 
    worry about it (e.g., for support for odd hardware on laptop), 
    grabbing a good w.x.y - level release seemed to be the best 
    policy.
  * GNU Emacs? They do seem to get their round-number releases OK, 
    but my casual impression is that most of their less-round-number 
    versions are OK too.
  * GCC? It's not clear to me that their round number releases have
    been all that solid.
  * OpenBSD did do, it seemed to me, a reasonably job of making their
    round number releases solid (at least modulo the differences in 
    s/w engineering taste which eventually drove me away). Still, 
    though, if you were security-conscious you were supposed to patch 
    more often than that. So if OpenBSD 6.3 is released in December 
    2009, and you want to install OpenBSD in April 2010, you're 
    supposed to get 6.3+patches; then it's not so clear to me this 
    is fundamentally different from getting sbcl-1.4.5 instead of 1.4.
While in many ways I have an irritatingly high opinion of myself and
the other SBCL developers, I am not sure that we can do this better
than the household names of free software. And, for that matter, we
might have to do better than commercial software too. The facts are
less public there, but my impression is that the situation is similar:
a month after release n.0, the n.0+patches version tends to be more
reliable than n.0.

One thing that does seem to work to give a qualitative improvement in
stability is periodically to take a pretty-good version, fork it as a
production version, and only port conservative fixes from the
development branch. As I vaguely recall from discussion on the list
some time ago, there wasn't much interest in maintaining such
production versions of SBCL. But if anyone becomes sufficiently
motivated, I don't think there are any great obstacles to doing it.

-- 
William Harold Newman <wil...@ai...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C
"When I am picking problems to work on, ones that stumped John von
Neumann go at the bottom of the stack." -- David Friedman, "Games,
Bargains, Bluffs, and Other Really Hard Stuff" in _Law's Order_