Help the kernel team help you

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 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 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 XXX
in backport suite

should be recent enough.

If you're running one of these versions,

then the upstream kernel developers
would probably be quite pleased to

receive your bug report.

Some subsystems in the kernel use
a bugtracker like Bugzilla

and many do not.

They just want bug reports XXX

to their development mailing list.

There's a documentation file called
MAINTAINERS

which we package.

You're gonna find it in the linux top 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
bugtracker 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 be able to see
status changes

if you reported in Bugzilla upstream.

Secondly, report bugs with the right
information.

The kernel packages we build include
some hook scripts

for the 'reportbug' command

so it can gather some diagnostic
information

and we generally expect that if your are
reporting a bug that is about

"This doesn't work on my machine."

then we want some diagnostict information
about your machine.

Running some commands might be useful,

it's not generally as good as XXX
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 version package

for example,
'linux-image-4.9.0.6-amd64'

would be the current kernel package
if you're running Stretch

on a 64 bits PC.

XXX 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 the driver.

This may seem obvious but people do
those things.

Adding features.

We do have some long-standing patches
in the kernel and 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 XXX has 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 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 maintainance.

XXX that's 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 get
automatically 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 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.

XXX to get a patch series
which is useful

if a fix takes multiple steps.