Without further ado
the first talk this morning is by
our beloved kernel maintainer Ben Hutchings
about "Help the kernel team to help you".
Hi.
[Applause]
As Michael said, I'm one of the kernel maintainers.
I've been on the kernel team for about ten years now.
So, I'm going to talk about
what Debian users and developers can do
when interacting with the kernel team
to make us more effective; more able to deal with your requests quickly.
We're quite busy.
There are about a dozen people
on the kernel team, but
most of us have other responsibilities within Debian.
Most of us are not paid to work on Debian either
so we only have a few hours a week to spend on it.
We get a constant stream of bug reports
some of which we can handle
some of which unfortunately we can't.
There's a large backlog of bug reports
that probably won't get dealt with in Debian.
They might get fixed upstream, but
we won't get to them.
One of the first things you can do to make our life easier is
report bugs upstream.
If you're running a recent kernel—and that doesn't have to be absolutely
the latest version that Linus released yesterday;
any version in testing, unstable, or experimental
or the current most recent backports suite
should be recent enough—
if you're running one of those versions
then the upstream kernel developers would probably be quite pleased to
receive your bug report.
Some subsystems in the kernel use a bug tracker like Bugzilla
and many do not—
they just want bug reports directly
to their development mailing list.
There's a documentation file called MAINTAINERS
which we package
—you can find it in the linux-doc package—
and that lists for each area of the kernel
the email addresses of maintainers,
the address of any relevant development mailing list,
and in some cases it will say they use a bug tracker at this URL.
That doesn't mean that you shouldn't report a bug in Debian as well.
If you report a bug in Debian and upstream
then use the standard "forwarded" command to link them together
and we should then be able to see status changes
if you reported in Bugzilla upstream.
Secondly, report bugs with the right information.
The kernel packages that we build include some hook scripts
for the "reportbug" command
so it can gather some diagnostic information
and we generally expect that if you are reporting a bug that is about
"This doesn't work on my machine"
then we want some diagnostic information about your machine.
Running some commands that you thought might be useful
is not usually as good as running all the diagnostic commands
that are in these scripts.
So the right way to report a bug in the currently running kernel
is just "reportbug kernel".
Reportbug knows how to look up the correct package for that.
Otherwise, you should report against the specific versioned package
for example "linux-image-4.9.0-6-amd64"
would be the current kernel package if you're running Stretch
on a 64-bit PC.
Don't file bugs against metapackages like linux-image-amd64
because those are basically just some metadata saying
"This is the current version of the kernel and you should install that."
Don't report bugs against firmware packages
unless you're really sure the bug is in firmware
rather than in the driver.
This may seem obvious but people do those things.
Adding features.
We do have some long-standing patches in the kernel, in the linux package.
We don't really want to add to those.
Most of those really ought to get cleaned up and sent upstream
but it requires time to do that.
So, new features should always be added upstream.
As soon as they're accepted upstream,
we're happy to add them into the earlier versions that we have in Debian
because we know that if they've accepted upstream
then as soon as we get to that new upstream version
we can drop that patch
so it's not adding to the long term burden of maintenance.
I've got a link there to the documentation on how to contribute to the kernel.
We would be very happy, well I would be very happy
if people would volunteer to work on those long-standing patches
and get them into a state where they would be accepted upstream.
So, you reported a bug upstream, and it got fixed.
That's great
but quite often that fix isn't going to get into a stable release
of the kernel for several months.
If the bug was actually found in a stable release,
rather than unstable or testing
then that fix might not automatically get into a stable update at all.
So, you probably want to tell us what the fix is
so that we can apply it now.
If you can give a reference to the specific commit, if you know that
that is absolutely ideal.
We can easily then dig out that commit and add it.
There's a patch tracking system used by many of the kernel mailing lists
called "patchwork" and that will gather together a patch and
all the discussion about it.
It also gathers together patch series, which is useful
if a fix takes multiple steps.
If you tell us that the patch was discussed on a mailing list and
link to an archive
that can work, but mailing list archives often mangle patches
so then we need to undo the mangling
so that takes longer to deal with.
If you simply send a patch to the bug tracker
without any link to "this is where it came from upstream",
that's actually kind of a problem because
we don't know whether that's really what you say it is.
If it's a signed mail from a Debian Developer
OK, yeah, we can probably trust it.
If it's not a signed mail or it's from a Debian user,
then we don't know.
So we need to actually look upstream to see
"This is the version that got committed."
If you want to do a backport from upstream to whatever is the current version
that's great, but you need to include the upstream reference as well.
Talk to us as a team.
From time to time, I will get mail directly to me, saying
"Oh there's this bug." or "Can you help me with this?"
or occasionally a company saying
"Oh, we want to update the support for our hardware."
They should not be mailing just me,
they should always—almost always—be sending bug reports
to the regular Debian bug tracker
and other mail should go to the debian-kernel mailing list.
We also have a development IRC channel, #debian-kernel on irc.debian.org
and some things can be discussed there.
Usually it's best to send longer messages as email though.
The only reason you would want to not use one of those public…
The only reason why you should not use those public channels is
if you're discussing a security issue that's currently not public
and shouldn't be made public until it's fixed
and in that case, do contact me directly
but also the Debian security team.
If you want to contribute to the packaging rather than…
if you don't want to touch the kernel code itself
but you want to contribute to the packaging
maybe you want to change the configuration;
maybe you want to make the packaging more suitable for use
by downstreams, derivatives;
if you simply want to improve the packaging in Debian;
patches to that are OK, merge requests are wonderful.
Since we moved to Salsa and can take merge requests
through the Gitlab software
I've found I can review and comment on and apply these changes
pretty quickly.
It also helps that we get a notification
for all the new merge requests on IRC
so that's pretty much instant.
If a team member is looking at the IRC channel and
has time available then they can deal with that
in minutes sometimes.
So, in the last…
I checked back in the git history and found in the last four weeks
that we used Alioth,
there appears to be only one patch to the linux package
that wasn't either picked from upstream or done by a team member.
In the last four weeks up to yesterday
we accepted 14 merge requests on Salsa.
So, this is a massive improvement to the productivity of the team and
our ability to accept outside contributions.
Once again, a reminder that feature patches for the kernel code itself
do need to go to upstream first.
So, that's about it
but I've got about five minutes for questions.
[Applause]
Are there questions?
[Q] Hi Ben, thanks for the lecture.
I am wondering what are those long- standing patches you mentioned.
Can you give a few examples for that?
[Ben] One of the things that actually requires the most work
when moving to a new kernel version is
we have a patch to, firstly, add specific log messages to the firmware loader
so whenever a firmware file is missing
it will always log that in a standard format.
This is useful for the installer, which uses that to detect missing firmware
and warn you.
And then, because many drivers also
log firmware errors in inconsistent ways
there's a second patch that removes those redundant log messages
and that one keeps getting conflicts when we update.
So really, those ought to get cleaned up a bit and sent upstream.
Further questions?
Well, if not, then let's thank Ben again.