Changing kernel API / Breaking VirtualBox - update criteria violation?

[Toshio Kuratomi]

On Tue, Nov 22, 2011 at 06:57:30PM +0000, Matthew Garrett wrote:
> 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?
> 
Yes.  Consideration ie: thinking.  Making an informed judgement is what the
policy requires.  Do you have to spend long, sleepless nights tossing and
turning and pulling out your hair over that one user out of our supposed
million?  No.  You can quickly evaluate and say that this is one user using,
as we're agreed on, an unsupported feature of our package and therefore
we're going to push a bugfix update anyway.  As I wrote in my reply to
davej, this can even be a decision that is applied in an ongoing manner
(What is the exception section of the policy, anyway but such decisions made
and applied at a more global level).

Here's a counter example of equally hypothetical proportions -- let's say
that you believe every user of Fedora 16 to rely on byte 0x9e0 of /bin/ls to
be 0xdf and that if that is changed Fedora 16 will need to be rebooted from
a rescue cd in order to be restored.  Would you say that that is something
that would not have to be considered under the update policy?

[snip]

> > 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.
> 
The fact that you and I are continuing to argue about this despite the fact
that we agree on the desired outcome would suggest otherwise.

I'm willing to do the work.  Opened up a ticket so I know what the desired
outcome is to look like:
  https://fedorahosted.org/fesco/ticket/706

-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/7ebcc4d5/attachment.bin