On Tue, Nov 30, 2004 at 02:06:18PM +0000, Christophe Rhodes wrote:
> Brian Mastenbrook <bmastenb@...> writes:
> > 1. Don't make any.
> > 2. Make the binaries without sb-unicode.
> > Or, if we make the binaries with unicode, there are two options:
> > 3. Touch test-passed in the sb-md5 directory and ship it, knowing that
> > users who use sb-md5 will see their MD5 computed values change.
> > 4. Don't touch test-passed and distribute without sb-md5.
> > 5. Some combination of #3 or #4 and #2.
> > My personal feeling is that option #3 is the right option: I'd like to
> > ship with unicode to get users testing, and it doesn't make sense to
> > not ship sb-md5 just because the tests haven't been fixed. However, I
> > could see an argument for #2 - waiting until there are encode and
> > decode to string functions before shipping binaries with unicode. #5
> > would be a lot of work.
> Again, speaking personally, I'd rather #4; that way, if anyone feels
> that they need sb-md5 in their binaries, they have an incentive to get
> down and make it happen. I see #3 as dishonest -- what is the point
> of having tests for contrib modules which we have always said have a
> slightly less supported status than the main body of code, if at the
> least provocation we circumvent those tests? It's not just a question
> of fixing the tests: the interface itself is broken, and despite two
> calls for contributions remains so.
> I believe Kevin has chosen option #2 for his Debian uploads -- in some
> sense, I think that covers that base; it seems to me that #4 is the
> option that best reflects the state of SBCL development at release
I think I agree with you (CSR) here. Choice #3 seems like promising
what SBCL doesn't (quite) deliver; I would prefer either #2 or #4. By
and large, SBCL tends to err in the direction of not promising what it
doesn't quite deliver. Not only is that direction my personal
preference, but I also have a metapreference: whichever direction we
prefer, we should try to prefer it consistently. Thus, if here we
really wanted to have defaults and summary information which
cheerfully promote things which sort of work, I'd be wondering whether
we should start converting other things to a similar approach.
Between #2 and #4 I don't have as strong a preference, but again I
have a metapreference for having a reasonably consistent policy. #4
looks like an instance of a policy that contrib/ maintainers are
fundamentally the ones responsible for chasing the main code (so when
the main code changes -- Unicode in this case -- and breaks something
in contrib/, the default policy is to release the main code and shut
down sb-md5 until it catches up). #2 looks like an instance of a
policy that the main system shouldn't do things which break the
contribs, starting to promote them to an equal part of the main
system. I think to the extent that we have an explicit policy, it
currently looks like the first, corresponding to #4. And I think if
it's time to make an exception to that policy, then maybe it's time to
think about changing the policy instead.
(I still prefer the #4-style policy, but I can see there are arguments
both ways, and quite some time has passed, and many changes have
occurred, since we argued about it last.)
William Harold Newman <william.newman@...>
"But I'll forgive you a good deal for calling it 'Interesting but slightly
mad.'" -- <http://groups.google.com/groups?q=ddfr+Interesting+but+slightly+mad>