 Without further ado, the first talk this morning is by our beloved kernel maintainer, Ben Hutchins, about how to help the kernel team to help you. Hi. So, as Michael said, I'm one of the kernel maintainers. I've been on the kernel team for about 10 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 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. So, 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 back port suite should be recent enough. If you're running one of those versions, then the upstream kernel developers will 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.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 that they use the bug tracker, this URL. That doesn't mean that you shouldn't report the bug in Debian as well. If you report the 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 report it in Bugzilla upstream. Secondly, report bugs with the right information. The kernel packages that we build include some hook scripts for the report bug command, so it can gather some diagnostic information, and we generally expect that if you're 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 usually not as good as running all the diagnostic commands that are in these scripts. The right way to report a bug in the currently running kernel is just report bug kernel, report bug knows how to look up the correct package for that, and otherwise you should report against the specific versioned package. For example, Linux Image 4.9.0-6.AMB64 would be the current kernel package if you're running a stretch on a 64-bit PC. Don't file bugs against meta packages like Linux Image, AMB64, because those are basically just some metadata saying this is the current version of the kernel, and you should install that. And 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 longstanding patches in the kernel, in the Linux package. We don't really want to add to 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 if they're 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 just got a link there to the documentation on how to contribute to the kernel. I would be very happy if people would volunteer to work on those longstanding 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. And if the bug was actually found in a stable release rather than an 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 the mailing list and linked 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 send a patch, simply send a patch to the bug tracker without any link to others 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, okay, 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 if this is the version that got committed. If you want to do a back port 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. Can you help me with this? Occasionally companies 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 ILC channel on ILC.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 the one of those public, the only reason why you should not use those public channels is if you're discussing 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. And so if you want to contribute to the packaging, if you don't want to touch the kernel code itself, if 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, making derivatives. If you simply want to improve the packaging in Debian. Patches to that are okay. Merge requests are wonderful. Since we moved to Celsa and can take merge requests through GitLab software, I found that I can review and comment on and apply those changes pretty quickly. It also helps that we get notification for all the new merge requests on ILC, so that's pretty much instant. If a team member is looking at the ILC 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 Celsa. So this is a massive improvement to productivity of the team and our ability to accept outside contributions. Once again, reminder that feature patches for the kernel code itself do need to go to upstream first. So that's about it. But got about five minutes for questions. 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? One of the things that actually requires the most work when moving to a new kernel version is we have a patch to... Firstly, it adds specific log messages to the firmware loader. So whenever a firmware file is missing, it will always log that in the 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. For the questions, well if not, then let's thank Ben again.