Re: Maintainers, porters, and burden of porting
Lucas Nussbaum wrote:
> We might chose to make ruby1.9.1 the default ruby implementation for
> wheezy (instead of ruby1.8). I still hope that all porting issues
> affecting ruby1.9.1 will be resolved.
> But if it's down to those four choices, what should I do in a couple of
> weeks, when the new upstream release will be available?
> (1) not upload the next ruby release to unstable until porting issues
> are fixed
> (2) disable the test suite on architectures where it fails, so that the
> package can build and migrate to testing (but it will be completely
> broken, which might annoy DSA, e.g because of puppet)
> (3) request removal of ruby binaries on architectures where it fails to
> (4) orphan ruby1.9.1 ;)
What gcc seems to do (though I may be understanding incorrectly) is
to allow the default version to vary by architecture. People
interested in a given architecture are expected to do some work to
allow a modern version to be used, and if that doesn't happen, it's a
bad sign and accounted for in the usual ways. Which I guess is
closest to (2) or (3), depending on the nature of the test failures.
I can understand if there are details involved that make that not
work here, though.