[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian i386 architecture now requires a 686-class processor



Guillem Jover writes ("Re: Debian i386 architecture now requires a 686-class processor"):
> On Wed, 2016-05-18 at 16:57:48 +0000, Sune Vuorela wrote:
> > On 2016-05-18, Julien Cristau <jcristau@debian.org> wrote:
> > > Why aren't those bugs RC?
> 
> That's indeed a good question! It would probably be best if a neutral
> party would do that. :)

I have an answer to the RC question.  I'm not sure if I count as
neutral, now that I have posted my other message, but:

> > Either we give both users on old hardware a bad experience or all the
> > users on new hardware a bad experience.

This comment is a bit opaque, to me.

> I don't follow, as I mentioned on the bug report, the patches I
> proposed use the JIT if the CPU supports SSE2, otherwise they fallback
> to use the interpreter, so no bad experience for anyone (because I
> consider silent failure to run at all, way worse than possibly running
> but slowly). And I'd probably characterize i386 as being there precisely
> to support old hardware by definition.

IMO the way to read "is a bug RC" is "if the bug is not fixed, would
Debian be better without the package, than with the buggy package".
This calls for weighing the harm caused by the bug to the people
affected, against the benefit of the package to other users.

In this case I think the class of affected users is big enough - and
there are generally enough alternatives - that the bug ought to be RC.
If the packages are removed from Debian, then those users will be
guided by our installation and package selection tools to other,
working, software.

ISTM there is definitely room for disagreement on this tradeoff.  I
guess these libraries may be dependencies for some programs which do
not have good alternatives, and of course imposing a UI change (by
switching to different programs) for a reason like this would be
rather poor.

So I hope that we can find a way to improve the technical situation
rather than escalating the disagreement to our slow-moving governance
arrangements (or, worse, ranting about it while everyone gets more
annoyed).

Thanks,
Ian.


Reply to: