Changing kernel API / Breaking VirtualBox - update criteria violation?

Matthew Garrett mjg59 at srcf.ucam.org
Tue Nov 22 18:57:30 UTC 2011


On Tue, Nov 22, 2011 at 10:49:28AM -0800, Toshio Kuratomi wrote:
> On Tue, Nov 22, 2011 at 06:28:06PM +0000, Matthew Garrett wrote:
> > Consuming the output of ls is a supported way to use ls. Building third 
> > party modules is not a supported way to use the kernel.
> > 
> That's not the criteria I see when reading the updates vision and updates
> policy.  I don't see supported there; I see whether we're breaking things
> the way end users are using them.

So just to be clear on this, you believe that if a user is relying on 
byte 0x9e0 of /bin/ls to be 0xdf on x86_64, then that is something that 
would have to be considered under the update policy?

> > It's clear that if we disabled the ability to build third party modules 
> > at all that the ability to use third party modules would be entirely 
> > irrelevant and clearly not a consideration. So just pretend that we've 
> > done that.
> 
> So that we can have this discussion again when a different package also
> breaks end user expectations without breaking ABI?  If we want to avoid long
> discussions that in the end boil down to different interpretations of the
> policies we need to take care to make our policies clearly reflect the
> meaning we intend.

If the relevant metric is "end user expectations", why didn't you just 
say that in the beginning? We should be clearer that any expectation 
that third-party modules will be usable over the course of a stable 
release is wrong. I've no problem with that. It's still not an issue 
with the updates policy.

> Clarifying wording may not be as fun as coding but it is necessary if we
> want to stop discussing the same points over and over with slightly
> different cases each time.

This case requires no clarification.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org


More information about the devel mailing list