Changing kernel API / Breaking VirtualBox - update criteria violation?

[Toshio Kuratomi]

On Tue, Nov 22, 2011 at 06:28:06PM +0000, Matthew Garrett wrote:
> On Tue, Nov 22, 2011 at 10:08:18AM -0800, Toshio Kuratomi wrote:
> > On Tue, Nov 22, 2011 at 05:12:12PM +0000, Matthew Garrett wrote:
> > > I don't know how much clearer I can make this. The update policy applies
> > > to the supported ABI of the package. For instance, if I have an 
> > > application that depends on byte 0x9e0 of /bin/ls being 0xdf and an 
> > > update breaks that, that's not a relevant consideration for the update 
> > > policy. The kernel module interface is not a supported ABI in Fedora. 
> > > It's simply not a relevant consideration for the update policy.
> > > 
> > I don't know how much clearer I can make this -- The updates policy applies
> > to more than the "supported ABI of a package".  For instance, if you have an
> > application that dependds on /bin/ls printing "?" when it encounters
> > a filename with a byte that cannot be decoded in the current locale and it
> > starts printing \001 instead, that is a relevant consideration according to
> > the updates policy.
> 
> 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.

> > > The policy is fine as is. The problem is your overreaching definition of 
> > > ABI. We could make it explicit that the module interface isn't an 
> > > exported ABI by modifying the loader so that third-party modules simply 
> > > can't be loaded at all and then this clearly wouldn't be an issue, but I 
> > > don't think anyone benefits from us doing that.
> > 
> > The definition of ABI is not at issue.  The reach of the updates policy
> > itself is.  If I'm understanding you correctly you think the updates policy
> > applies to a much more limited scope of changes than I do.  I would suggest
> > that that is an indication that the updates policy needs to be reworded in
> > at least certain places so as to more clearly illustrate whether it has
> > a broad scope (in which things like ABI are examples of criteria for
> > deciding not to issue an update) or limited scope (in which ABI is one of
> > the specific criteria for decding to withhold an update.)
> 
> 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.

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.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20111122/ddc91832/attachment.bin