On Tue, Nov 22, 2011 at 04:23:28PM +0000, Matthew Garrett wrote:
On Tue, Nov 22, 2011 at 08:12:42AM -0800, Toshio Kuratomi wrote:
> On Tue, Nov 22, 2011 at 03:08:07PM +0000, Matthew Garrett wrote:
> > We don't support out of tree kernel modules at all, so they're not
> > considered when making the determination about whether an update is
> > appropriate for a stable update.
> >
> Nonsense. We don't support them but the updates policy as written covers
> them. I quoted the places in the policy in my other mail. If you don't
> like what the updates policy says then change the updates policy to remove,
> amend, or clarify those sections.
The kernel ABI is the syscall interface, /sys and /proc. There is no
stable module ABI between kernels - even with a small security update,
the symbol versioning may change in such a way that the module ABI will
change. Given that any interpretation of the stable update policy that
prevented us from ever providing kernel security updates would be
absurd, that's clearly not the correct interpretation. And if the module
ABI isn't supported, nor is the API.
That's not a logical conclusion. As I said in both my previous emails, the
updates policy allows the maintainer to decide that the benefits of a new
version outwiegh the problems. According to the updates policy the
maintainer needs to consider that their change will cause problems for third
party kernel module packagers and end users that are compiling their own
kernel modules. The policy does not require that the kernel maintainers
weigh this more heavily than the need to provide security updates (or new
hardware or major bugfixes).
If you're steamed up that the policy requires maintainers to consider their
impact on end users at all, the onus is on you to make a change to the
policy. As long as the policy gives the maintainer the ability to explain
how the pros and cons of updates stack up in their view, however, it doesn't
seem nearly as bad as you make it out to be.
-Toshio