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