|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|## page was renamed from KernelTeam/FAQ|
|Line 5:||Line 6:|
|Welcome to the KernelTeam FAQ! The aim of this page is to provide an up to date list of common questions that we get. We encourage you to update this document when something is missing so it becomes a core source of information for the project.||Welcome to the [[Kernel]] Frequently Asked Questions (FAQ)! The aim of this page is to provide an list of common questions that we get. We encourage you to update this document when something is missing so it becomes a core source of information for the project. Each question has its own page which are listed on the [[Kernel/FAQEdit]] page, which also contains guidance on editing the FAQ.
= Getting Help =
|Line 9:||Line 14:|
|== Can I get a patch included in Ubuntu's kernel? ==||<<Include(^Kernel/FAQ/General.*)>>|
|Line 11:||Line 16:|
|See KernelTeam/KernelPatches.||= Testing Questions =|
|Line 13:||Line 18:|
|== The Ubuntu kernel config produces huge packages ==||<<Include(^Kernel/FAQ/Testing.*)>>|
|Line 15:||Line 20:|
|Our build includes CONFIG_DEBUG_INFO in order to produce linux-debug-image packages. We then manually strip the modules after build.||= Debugging Questions =|
|Line 17:||Line 22:|
|If you re-use our config for your own build, your best bet is to change this line in the config:||<<Include(^Kernel/FAQ/Debugging.*)>>|
|Line 19:||Line 24:|
|= Triager Questions =|
|Line 23:||Line 26:|
|Line 25:||Line 28:|
# CONFIG_DEBUG_INFO is not set
|= Developer Questions =|
|Line 29:||Line 30:|
|== I get dm-linear errors upgrading to gutsy ==||<<Include(^Kernel/FAQ/Dev.*)>>|
|Line 31:||Line 32:|
|We've removed a long time patch to our kernel to work around problems in evms. This patch creates more issues than it "fixes". Please see this FAQ for work arounds: http://evms.sourceforge.net/install/kernel.html#bdclaim||= Maintainer Questions =|
|Line 33:||Line 34:|
== Gutsy Special Sauce Patches ==
Here is a list of patches applied to the Gutsy kernel that are not already upstream. In general I ignored all patches related to Sparc, Unionfs, and Apparmor since all of these patches are upstream or are available for the 2.6.24 release.
commit aaed87be2dd4cd3499b092d429e805a50dd797c1 UBUNTU: acpi_scan_rsdp() breaks some PCs by not honouring ACPI specification
commit f2659689109662e4fc2d8755822df63a70c74554 UBUNTU: Disable MMCONFIG by default
commit 82e59f13411108d58e7681ca7ac18a0f7849d4a5 Use compat_sys_getdents
commit 66229db6579602007bf8a509da68de1057aaaf13 UBUNTU: PPC: Only set hwif stuff when ide-core is non-modular
commit 713cf916be1ce74fe96dc1a14fc260469a095606 UBUNTU: i386/x86_64: Allow disabling the putstr's from compressed boot wrapper
commit 9e9eb927bb9ea73c58464ef43397139cbcecc098 UBUNTU: ACPI: Allow custom DSDT tables to be loaded from initramfs
commit 82a5e08bfbbde060471d00821f70c6977eec01a6 UBUNTU: Fix ACPI battery detection on Asus (is upstream in 2.6.24)
commit b478b18f0842c250dc7ff33da531ba8f83975bad UBUNTU: fix memory leak in psparse.c (caused by 412c7581742c216b6ae0db311fde1401639b7097)
commit 412c7581742c216b6ae0db311fde1401639b7097 UBUNTU: Add infrastructure for notification on ACPI method execution (sent a note to Matthew Garret about the suitability of this patch for 2.6.24)
commit 40882cdc77d00b31a1fa111593084f756858e646 UBUNTU: toshiba_acpi: Don't use init_MUTEX_LOCKED (got rewritten in 2.6.24, no longer uses exclusion)
commit 350cae05ebcac655bbd63dcc3e1fe972a257d01e UBUNTU: Catch nonsense keycodes and silently ignore
commit 622d3fb8a0200a4448c340d874239aad53c46034 UBUNTU: RTC: Ratelimit "lost interrupts" message (is upstream in 2.6.24)
commit be70e2f756c77106efab4bc687d6c5c3021a96bd UBUNTU: input: Allow root to inject unknown scan codes. (no longer looks applicable in 2.6.24)
commit e22ad0ffa59fdfb5186e205e49d190718c772c93 UBUNTU: Guest OS does not recognize a lun with non zero target id on Vmware ESX Server
commit 272c0f4564a1b28c16bb0d7ebf830cffb77d722b UBUNTU: Disable Thinkpad backlight support on machines with ACPI video
commit bf5101b3f97631f0d42a62fb84a928ac49795ae5 UBUNTU: scp big file causing General Protection Failure (obsoleted upstream in 2.6.24)
commit 9f759941b606b7cb19556fe198298f62a745a3bb UBUNTU: irda: Default to dongle type 9 on IBM hardware
commit de50a2d8f0b6227a8b35a3db81bcb19c1107d235 UBUNTU: tulip: Fix for Uli5261 chipsets.
commit 8dedc62d72d630b6278420dad36652bfc7fd99b1 UBUNTU: hostap: send events on data interface as well as master interface (should be submitted upstream)
commit a2fe680ed1138fc8cc2a18bd5ccebe12d9e27792 UBUNTU: hostap: send events on data interface as well as master interface
commit 1e0e565b6e11292c6a55888f9eeacb2fbbdaf0d1 [PATCH] Update my email address from email@example.com to firstname.lastname@example.org
commit d0ecf29b6abcd567121e63aa43f06e7c587d89e7 [PATCH] Fix ipw2200 set wrong power parameter causing firmware error
commit ece5706a49347741be17f0e304bdadbace94babd UBUNTU: fix orinoco_cs oops
commit 0fd77efbd8364d6a2625bbc4b84c1f3c26387655 UBUNTU: orinoco_cs.ko missing
commit 59a982ddda55bdaf031e8b5d593d18b5b5215484 UBUNTU: Disable MSI by default
commit f5e0c9fa067147317a935dd74459e69771465886 UBUNTU: VIA southbridge Intel id missing (should go upstream)
commit 2e1b0a4653a0d96c253782a9e9369125e59d9303 UBUNTU: [USB] USB] Support for MediaTek MT6227 in cdc-acm. (should be pushed upstream)
commit f887b63133717e34ee6e7ece58823bebd61547df UBUNTU: Reorder quirk list based on Vendor/Product ID
commit d97f7da8c1eb422d9741a8dac3037820eb1e7c42 UBUNTU: [USB] Added support for Sprint Pantech PX-500.
commit a727fc07ca823a665492a40ace45c4b0df542c74 UBUNTU: [USB] Add support for Toshiba (Novatel Wireless) HSDPA for M400.
commit 6a7024949b3c26ce3027995218159d49b151ff67 UBUNTU: Enable Sierra Wireless MC8775 0x6813
commit dee610d11dfdf343182a2f800c0cf0e15f21bd5d UBUNTU: [SIERRA] Adds support for Onda H600 ZTE MF330
commit 1861cba4ed52e9aea617e980a033a840c3e15b90 UBUNTU: Nikon cameras need support in unusual_devs.h (should go upstream)
commit cd0013d7c79aad79f9d43884a6662f398633b988 Clean up sti_flush
commit b58027d9b457c6636f9ec950369a164d2352fff3 UBUNTU: vesafb is not for ia64
commit b736680a1237aa73abde83bfea0f0a68eb787d57 UBUNTU: Modualrize vesafb
commit 4eaaffcbe0320ab4243910529661a22711833965 [DLM] dumping master locks
commit 9652aaa486ebd97f2692a2f4d044ccf6003a27b3 [DLM] fix reference counting
GFS2 has a bunch a tweaks that are not upstream. I think I would confer with the maintainers and find out what it should be.
apparmor 10.3 has patches in a number of places. Rather then advertising the Gutsy patches, go get the current apparmor from upstream.
commit eebfe199c8c32f8b8b8b31d97934d3690d32679b UBUNTU: fix NFS mounting regression from Edgy->Feisty
commit 3d3d578b38d8d8a3a1c8e6deafe945355151e65d UBUNTU: version: Implement version_signature proc file.
commit 4d618476aa320dc0b6b602b549c7ee5dd2f3db81 UBUNTU: kmod: Improve call_usermodehelper_pipe to handle data close (seems like this ought to go upstream)
commit 792d74f73b02c696b5be9769cf21be5571eb61dd UBUNTU: PCI: export __pci_reenable_device(), needed for ata_piix change (this was cherry picked from upstream, but the 2.6.24-rc2 implementation looks quite different. needs investigating)
commit 5b4efc85b51dc5028e8095ca63a4040922b04ad2 UBUNTU: bluetooth headset patch (should bug Marcel about getting this upstream)
commit 06cafb54e40e46535bdc1abdbe4d7d2fdaca9824 UBUNTU: pm: Config option to disable handling of console during suspend/resume. (investigate this to see if its still relevant given upstream work on suspend/resume)
commit a10df6bc15d12d3efeef35008337f6df7978273c UBUNTU: Cause SoftMac to emit an association event when setting ESSID. (this isn't upstream, but it may be moot)
== Hardy Special Sauce Patches ==
commit 6d896b6292554a90601676ce4a85597f00feea2a UBUNTU: SAUCE: [GFS2] Export symbols required by GFS1
commit 81d77404a005614b9f47c32cd5ce1ff91d7fa435 UBUNTU: SAUCE: acpi_scan_rsdp() breaks some PCs by not honouring ACPI specification, commit 92c445ed6aaa4a6f89f23bc61c000a94b67a9e33 fix compiler warning
commit 72ade3953bd960d8358536383e3c4a44532df0c4 UBUNTU: SAUCE: Disable MMCONFIG by default
commit 59ba0ac59fa9b578e0d43580e29857560e31a7a1 UBUNTU: SAUCE: PPC: Only set hwif stuff when ide-core is non-modular
commit 6c035936f62d58fce2840d70c8d4601cc1182d1c UBUNTU: SAUCE: i386/x86_64: Allow disabling the putstr's from compressed boot wrapper
commit 17d25493aa65df8d411b8945878c21da8b4abbbf UBUNTU: SAUCE: ACPI: Allow custom DSDT tables to be loaded from initramfs, commit 562a88329433e24a08cfbe2031ecd3632c3d0731 Update configs.
commit c7078325ef61b32164f5280d3b58b7286219e385 UBUNTU: SAUCE: Catch nonsense keycodes and silently ignore (should go upstream)
commit 37d9b096aa958590d8f12796a36f52317cb2a952 UBUNTU: SAUCE: Guest OS does not recognize a lun with non zero target id on Vmware ESX Server (should go upstream)
commit 346b138ea5b732091af07b104f963d8de38cbf14 UBUNTU: SAUCE: Disable Thinkpad backlight support on machines with ACPI video (check with Matthew Garret about upstream suitability)
commit 02b231b59f7edf39d0a942b3f8ff5cedd926fc44 UBUNTU: SAUCE: irda: Default to dongle type 9 on IBM hardware (should go upstream)
Welcome to the Kernel Frequently Asked Questions (FAQ)! The aim of this page is to provide an list of common questions that we get. We encourage you to update this document when something is missing so it becomes a core source of information for the project. Each question has its own page which are listed on the Kernel/FAQEdit page, which also contains guidance on editing the FAQ.
Something is wrong and I do not know where to start?
I have a kernel problem where do I go?
If you have a problem which is related to the kernel you should visit the #ubuntu-kernel IRC channel on Libera.chat (See How do I find the kernel team?).
I have problems with Ubuntu where do I go?
If you have general issues you should visit the #ubuntu IRC channel on Libera.chat, people here can help you work out where your issue is and to files bugs on it.
Where do I find the Kernel Team's documentation?
How do I find the kernel team?
The Kernel Team is primarily IRC based as we are located in disparate cities throughout the world. We typically hang out on the #ubuntu-kernel channel on Libera.chat, please be patient if we seem to be quiet. See the KernelTeam page for more details.
How do I get involved with the Ubuntu Kernel?
The kernel team is always interested in getting community help on the kernel. We need help triaging incoming bugs, reviewing patches proposed for the kernel, as well as helping to fix launchpad bugs. For more details see Kernel/GettingInvolved.
Is there any process documentation for the roles within the Ubuntu Kernel Team?
Some of the activities which are the responsibility of the Ubuntu Kernel Team are documented in the team handbooks, see the Kernel/Handbook section of the documentation.
What do you need help with?
We need help with all aspects of the maintenance of the kernel. Probably our biggest project is triaging all of the incoming bugs filed against the Ubuntu kernel, you can help us to categorise these and get the necessary information to allow a developer to work on them, see Kernel/BugTriage for information on how you can help.
How does a Kernel Team script determine what Ubuntu series the bug was filed against?
The algorithm for determining the series a bug was filed against is given below. The order is significant and indicates the order the checks are made. As soon as a series is found, no further checks are made:
- Look in the bug description for:
"DistroRelease" which apport has been putting into the description for quiet some time.
- "Linux version string"
- "Description:" name/value pair which can contain the series version.
- "Release:" name/value pair which can contain the series version.
The string: "Ubuntu <series>".
- Look in log files that the original submitter has attached to the bug:
- "Dmesg.txt" / "dmesg.log"
- Look at the tags that have been added to the bug for a valid series. Note, there can be multiple specified so the first one found "wins".
- Look in the bug title for a valid series name. Again there can be multiple and again, the first found "wins".
How do I report a problem with the Kernel?
Details on how to file a kernel bug can be found on the Kernel/Bugs page.
LTS HWE Stacks
The latest information on the Ubuntu Lifecycle and Release Cadence.
The Ubuntu LTS enablement (also called HWE or Hardware Enablement) stacks provide newer kernel and X support for existing Ubuntu LTS releases. These enablement stacks can be installed manually but are also available when installing with Ubuntu LTS point release media. These newer enablement stacks are meant for desktop and server and even recommended for cloud or virtual images.
For more information, please refer to https://wiki.ubuntu.com/Kernel/LTSEnablementStack
Where can we find your Mailing List?
As with the majority of teams our major decisions are discussed and recorded on the Ubuntu Kernel Team mailing list. Join our mailing list at https://lists.ubuntu.com/mailman/listinfo/kernel-team. You can read an archive of messages at https://lists.ubuntu.com/archives/kernel-team
My bug is Fix Committed but the fix is not in the kernel?
Once a fix has been reviewed and approved on the Kernel Team email list it will then be applied to the kernel git tree. When sufficient updates have accumulated a -proposed kernel will be uploaded; you need the proposed pocket enabled to get these kernels. It can take some time before these changes are uploaded, however every day the tree is checked and if there are any new patches a new pre-proposed kernel is automatically uploaded to the kernel team pre-proposed PPA ppa:~kernel-ppa/pre-proposed. Adding both the proposed pocket and the pre-proposed PPA will get you all pending fixes as soon as possible. See Kernel/Dev/KernelTesting for details.
How do you manage and track incoming patches?
Patches are submitted to the Ubuntu kernels via the kernel-team mailing list. We use this list as the primary record of the discussions, acceptance, or rejection, of each patch (see Kernel/FAQ/GeneralMailingList). We use the patchworks patch tracking system to aid in this process http://patchwork.ozlabs.org/project/ubuntu-kernel/list/. See Kernel/Handbook/Patchworks for documentation on how we use patchworks within the team.
Which kernels does the Kernel Team support?
The Kernel Team provides support (security updates etc) for the Ubuntu kernels on all currently active releases, we do not support any non-Ubuntu kernels. A full list of the currently active releases can be found on the Releases page. For Long Term Support (LTS) releases, starting with Ubuntu 12.04, the desktop kernels and server kernels both receive five years support, this is reflected in the Releases page.
What differentiates the Ubuntu Kernel from the upstream Linux Kernel?
Ubuntu kernels are rebased against stable releases only through the development cycle, with many patches on top of the stable tag. Once the final release is made the master branch is never rebased again. While stable updates (post release) are usually applied, we sometimes make patch decisions that are counter to the stable releases.
So, the best one could say is that Ubuntu kernels are only loosely based on upstream stable. You'd have to examine the changelog to know exactly what goes into a particular kernel.
With every Ubuntu kernel release, we attempt to remain as true to the upstream Linux kernel as possible. However, there are inevitable patches which we carry on top of the upstream Linux kernel which differentiates the Ubuntu kernel from the upstream Linux kernel. This document attempts to describe the general set of patches which are carried and why: Kernel/FAQ/UbuntuDelta
What does a specific Ubuntu kernel version number mean?
The official version of an Ubuntu kernel tells you a number of things, including the base upstream version, the current Ubuntu ABI identifier and the kernel flavour. (See How can we determine the version of the running kernel? to find your current version number.)
Given a version like 2.6.35-6.9-generic this can be broken into four parts as below:
<base kernel version>-<ABI number>.<upload number>-<flavour>
The base kernel version represents the mainline version on which the Ubuntu kernel is based. The ABI number represents significant changes in the kernel Application Binary Interface. The upload number is a monotonically increasing counter for each upload of this base version. The flavour indicates which kernel configuration variant this is (See What is a Kernel Flavour?).
How can we determine the version of the running kernel?
The official version of an Ubuntu kernel is found in the /proc/version_signature file. This file contains both the full Ubuntu version of the kernel and the mainline version on which it is based. The first field is always Ubuntu, the second field is the Ubuntu kernel version, and the final field is the upstream version:
$ cat /proc/version_signature Ubuntu 2.6.35-6.9-generic 2.6.35-rc3 $
Given an Ubuntu kernel package version how do we find the exact mainline release it is based on?
The exact upstream mainline tag from which the Ubuntu kernels were forked can be found in the mainline kernel mapping table.
Given an Ubuntu kernel package version how do we find the release it is from?
The kernel package version is of the following form 2.6.35-6.9. The numbers before the - represent the base upstream version from which this kernel was forked, the first number following the - represents the ABI number, the final number is an upload number. Taking the package version first remove the upload number, then round the ABI number down to the nearest hundred (which can include 0), for example:
2.6.35-6.9 => 2.6.35-6 => 2.6.35-0
Look up the final version in the Kernel/Dev/TopicBranches mapping tables (see Current Branches). Once you have the release and branch you can obtain the source.
Where can I find out what the Kernel Team is doing?
The Kernel Team has a weekly status meeting to report on progress and to discuss issues. These meetings are held on #ubuntu-meeting on Libera.chat every Tuesday at 1700 UTC. Meeting agendas and previous meeting minutes can be found at KernelTeam/Meeting. There is also an accumulated live status for the current development release tasks, see Kernel/Release.
Why did a bot come along and mark a bug "Won't Fix"?
The reason the bug was marked as "Won't Fix" is because it was filed against an Ubuntu series that is no longer supported. Which series a bug was filed against is determined by a number of methods based on the data the original bug submitter provided.
The linux project within Ubuntu has over 6500 open bugs filed against it. There is a constant stream of new bugs coming in every day. There is no way the 8 person kernel team can stay on top of all those bugs. Therefor we employ a number of scripts to help with some of the trivial management of the bugs.
The purpose of marking bugs as "Won't Fix" is to indicate to those that care, that the bug will not be looked at any longer. It also tells them that if the bug does still exist on a supported series, they should just open a new bug.
We don't claim that the script is perfect and won't impact some bugs that it shouldn't. The kernel team will continue to refine its scripts as time goes on.
I heard the Kernel Team were asking for testing, where can I find details?
The currently open Calls for Testing are listed on the Kernel/Testing page. All open and closed calls should be listed there. We are obviously most interested in testing on the open calls.
I have problems with my system how can I diagnose the issue?
There are a number of specific diagnosis guides for kernel related issues in the Kernel/Debugging guide. You should likely file a bug against the linux package in LaunchPad if you do no already have one. File a bug using the command below:
Do we have upstream kernels for Ubuntu?
The kernel team does build upstream kernels for debugging use. These are built automatically as the upstream kernels release and published in the KernelTeam/MainlineBuilds archive.
Why do mainline kernel builds have a -<series> suffix?
Each mainline build is named by the base upstream version suffixed with an Ubuntu release name, 2.6.35-maverick. This tells us the upstream version which was built, and additionally which configuration was used to build it. This tells us which release is most compatible with the kernel as built. This does not prevent the kernel being used on other releases, though it is most likely to work correctly on the release it is build for, or earlier ones. The further away from your base kernel release you are the more likely that there will be an incompatible userspace interaction which will prevent them working for you.
Do mainline kernel builds include Ubuntu specific drivers?
By definition the mainline kernel builds are made from virgin unaltered mainline kernel sources and therefore do not, and should not, include any Ubuntu patches or drivers. There are also no binary drivers for these kernels.
What is Bug Triage?
Bug Triage is the process of vetting incoming bugs to ensure they have all the information they need to be worked on. See Kernel/BugTriage/Process for details on the process itself, see Kernel/BugTriage for pointers on triaging.
What is meant by Triage Levels?
We refer to the increasingly detailed and technical reviews of incoming bugs as Triage Levels, currently there are three triage levels. More details can be found at Kernel/TriageLevels.
Where can I find Triager resources and documentation?
We maintain a wiki of triager resources to share across the team and the community in the kernel team wiki in the Triage section, Kernel/BugTriage.
When I try to build the kernel I get an error telling me to run "make mrproper" what should I do?
This implies there are left over files in your tree which are not meant to be in a clean tree. A clean source tree is required for an out of tree (make O=<directory> style) build, which is what the Ubuntu packaging uses. The most common cause is the creation of the include/config directory. You can try removing this:
If that does not work it is normally safest to clean all extraneous file out of your tree as below. Note that this removes each and every file which is not committed to git, it will remove any patches etc you have lying around within the build directory:
git clean -x -f -d
Where can I find Development resources and documentation?
We maintain a wiki of development resources to share across the team and the community in the kernel team wiki in the development section, Kernel/Dev.
What is a Kernel Flavour?
It is impossible to build a single kernel for every occasion, any such configuration cannot be optimal for all use cases. As a result we offer a number of kernel variants for each release, these variants termed flavours. We commonly refer to those flavours using the flavour name, for example: generic, generic-pae, and server.
How do we choose which Flavours are supported in a release?
At the Ubuntu Developer Summit (UDS) we will discuss the current flavours and their applicability. During this discussions we will make recommendations for additions to or removals from the supported flavours. Those recommendations feed into the development for that upcoming release.
What are Kernel Flavour transitions?
Over time the supported kernel flavours have evolved. This means that sometimes it is necessary to move from one kernel flavour to another for a specific use case. More details on why we might need such transitions, and information on the transitions which have been needed previously can be found on the Kernel/Dev/Flavours page.
What Kernel Flavours exist for each release?
The flavours available for all supported releases are documented on the Kernel/Dev/Flavours page. This includes information on where support is obtained for these flavours.
Can I get a patch included in the Ubuntu Kernel? / How can I submit a patch to the Ubuntu Kernel?
Normally we consider patches for inclusion which are sent to the email@example.com email list. See Kernel/Dev/KernelPatches for more details.
Why does a local build produce such enormous packages?
Our build includes CONFIG_DEBUG_INFO in order to produce linux-debug-image packages. We then manually strip the modules after build.
If you re-use our config for your own build, your best bet is to change this line in the config:
# CONFIG_DEBUG_INFO is not set
Where can I find Kernel related bugs to work on?
The Kernel bugs are maintained in LaunchPad, the full list is at https://bugs.launchpad.net/ubuntu/+source/linux/+bugs
Where can I find the Ubuntu Kernel source code?
You can access all the kernels for previous and current development releases at http://kernel.ubuntu.com/git. There are repositories for each supported release under ubuntu/ubuntu-<release>.git. We use git to maintain all our trees. See Kernel/SourceCode for more details.
What are the supported Kernel Meta Packages?
The Ubuntu kernel meta packages facilitate the use of the different supported kernel flavors. These meta packages group a set of existing kernel related packages into a single set. Information documenting the set of supported kernel meta packages can be obtained at Kernel/Dev/Meta-Pkgs.
What are these topic branches in the Ubuntu Kernel?
Normally all of the source code for the Ubuntu Kernels are stored on the master branch of the Ubuntu git repository for a release. However where there are significantly different kernels for different systems, for example it may be at an older mainline level, or may contain very invasive changes, those cannot be merged safely into the master branch. In this case the source code is maintained on a topic branch (see Kernel/Dev/TopicBranches). We use a split debian system to allow these to cleanly coexist in the same repository (see KernelTeam/AbstractedDebian)
How do I use git with the Ubuntu kernel?
git is a fairly complex program to use and you are recommended to read up on and understand git's philosophy before attempting to work with the Ubuntu kernel trees, we recommend at least reading the Git Community Book. Once you are conversant with git you should read the KernelTeam/KernelGitGuide which describes how to find our respositories and how we use them. You may also find the KernelTeam/GitCheatSheet useful.
There are also 2 books that we know of:
- Pragmatic Version Control Using Git by Travis Swicegood
- Version Control with Git by Jon Loeliger
Why is feature X not enabled in the Ubuntu Kernel?
Often features have never been requested before and therefore not enabled, in other cases they may be incompatible with other features and cannot be enabled. Contact the Kernel Team (See How do I find the kernel team?) and ask.
Why is patch X not applied to Release Y?
It is not always possible to backport a fix to an older release. The key requirement for any changes applied to older releases is that they not introduce any regressions for other users. The fix may help your case but cause issues on other systems. This introduces risk in releasing fixes in older releases and may sometimes prevent us fixing your problem. Often we will only be able to fix these types of issues in the next release. This is outside the kernel team's control, see the StableReleaseUpdates and KernelTeam/KernelUpdates pages for details.
I have uploaded a new Ubuntu kernel, who needs to know about it?
A number of groups are affected by new Kernel uploads we therefore send out an announcement email to a number of groups for each upload. We announce each Kernel upload to the people indicated in the Announce kernel uploads section of the KernelTeam/KernelMaintenance guide.