converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 18:||Line 18:|
|* ["DebianKernelABIChanges"] - ABI changes; what they're for and why the suck||* [[DebianKernelABIChanges]] - ABI changes; what they're for and why the suck|
- Introduction - Who are we, and what do we do?
?DebianKernelPackages - What packages does our team create, and what are they for?
?DebianKernelFilingBugs - What is the right way to file a bug?
- What bugs should be filed against the 'kernel' package, vs. a real package.
- Classes of bugs
- Build issues
- Runtime issues
DebianKernelPatchAcceptanceGuidelines - What requirements must a patch fulfill before we will include it
?DebianKernelAndDebianInstaller - Interacting with the debian-installer team (l-k-di)
DebianKernelABIChanges - ABI changes; what they're for and why the suck
- Exist for module compatability
- Break upgrades (anecdotal ia64/vfat issue?)
- How ABI breaks break debian-installer
- Testing for ABI breaks
?DebianKernelBuildingModules - How to build additional modules for our precompiled kernel-images
?DebianKernelArchitectureSynchronization - How the architectures work together (or not) - sharing configs, build system; sharing source vs. kernel-patch-ARCH packages.
- All-kernels-from-one-source-package plans. Sven Luther has been looking into building most (or all) of our kernels from a single source package. What are the benefits? What are the bottlenecks? What is the status?
- What areas can we use help?
KernelFirmwareLicensing; what is acceptable and what's not. This topic maybe one to avoid, due to its political nature. It maybe better to fork this off into a BOF.