Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #64227

Bug#929557: Some Thoughts

Cross-posted to 2 groups.

Show all headers | View raw

The linux Kernel introduced an upstream commit designed to remove an
interface that was being misused.

That does not meet the kind of requirements for changes that we (Debian)
make in stable releases.
If I filed an unblock for krb5 to remove an interface at this point in
the release process it would be outright refused.

Even if krb5 had multiple levels of visibility and even if I filed an
unblock to change interface visibility it would be refused.

Even if I filed an unblock to change interface visibility to prevent
other people from violating the krb5 license it would be refused.

We are more permissive in what changes we accept from the kernel team.
There are a lot of reasons for that.  But I think it's more that we're
changing the default for changes from the kernel team, than that we
necessarily want the kernel team to be more able to break other software
in stable than other packages.

That is, if we had the resources to review the changes adequately and do
adequate testing, I actually suspect we would hold the kernel to the
same standards we hold other packages to.

I do not think this particular change would meet those standards for
buster.
I think this change clearly meets those standards for unstable.
And yet, as I said above, we do hold the kernel to different standards
for stable releases for a variety of reasons.
However, even if the default is that we are more permissive with the
kernel, we can review the complex cases on a case by case basis.  And we
should review that based on what is best for Debian, not what is best
for the kernel team.

I'm not saying the kernel team should revert the commit.
I'm saying that the issue is far more complex than has been outlined in
this bug so far.

I think that the kernel team and the ZOL maintainers should work with
the stable release team for buster to figure out which changes are
permissible.
Ultimately I'd expect that the stable release team will get to decide
which changes they want in buster and I hope that the kernel team and
the ZOL maintainers will work with that.

Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#929557: linux: restore __kernel_fpu needed for zfs for AES-NI/AVX support [mainline not in debian yet] Chris Zubrzycki <debian@mid-earth.net> - 2019-05-26 04:20 +0200
  Bug#929557: linux: restore __kernel_fpu needed for zfs for AES-NI/AVX support [mainline not in debian yet] Bastian Blank <bblank@thinkmo.de> - 2019-05-26 14:10 +0200
    Bug#929557: linux: restore __kernel_fpu needed for zfs for AES-NI/AVX support [mainline not in debian yet] Ben Hutchings <ben@decadent.org.uk> - 2019-05-26 19:00 +0200
  Processed: Re: Bug#929557: linux: restore __kernel_fpu needed for  zfs for AES-NI/AVX support [mainline not in debian yet] "Debian Bug Tracking System" <owner@bugs.debian.org> - 2019-05-26 19:00 +0200
  Bug#929557: Please revert LTS kernel change that will break ZFS for Buster point releases Mo Zhou <lumin@debian.org> - 2019-06-04 03:50 +0200
  Processed: Re: Bug#929557: Please revert LTS kernel change that  will break ZFS for Buster point releases "Debian Bug Tracking System" <owner@bugs.debian.org> - 2019-06-04 04:50 +0200
  Bug#929557: additional point of view Geert Stappers <stappers@stappers.nl> - 2019-06-04 07:30 +0200
  Bug#929557: Some Thoughts Sam Hartman <hartmans@debian.org> - 2019-06-06 18:30 +0200
  Bug#929557: Some Thoughts Chris Zubrzycki <debian@mid-earth.net> - 2019-06-18 00:30 +0200

csiph-web