Bug triage ========== We have far too many bugs and far too few get closed. What can we do improve this? => close anything tagged moreinfo and really without response for several months => close anything opened against version now unsupported, with message about how to reopen => BSP for kernel only, maybe in person at Linux Hotel => use 'newcomer' tag where appropriate Also could refer to kernel handbook bug chapter in reportbug script Kernel flavours =============== Currently we build very few flavours for most architectures. Ideally we can rely on system firmware or device tree to insulate kernel image from platform specifics. This leaves fundamental CPU and kernel features like 32/64-bit, page table format, RT as the main differentiators. Most architectures now build linux in just a few hours, so maybe we could add some more flavours to them: * Kernels for small VMs (PV drivers built-in, other drivers disabled, no initramfs needed)? * RT on more architectures? * Anything else? => maybe a 'server' flavour like Ubuntu? but we're not sure how that's different => otherwise everyone generally happy with current packages => they are large, though; waldi suggests maybe splitting out more obscure modules => not new flavours, but we could turn on debug info for all architectures now that ddebs are supported Testing ======= Some self-tests included in source tree and can be run through autopkgtests, but many fail! * If upstream is not checking them, should we bother? * Are other test suites like xfstests and LTP feasible to run completely automatically? (Note, ci.debian.net isn't yet able to run tests in a VM, but should be later.) => aside from autopkgtest, would be good to test hardware support through LAVA Packaging in git - what next? ============================= For the non-native packages, linux.git and linux-tools.git, only the debian/ directory is in git. Can we merge in upstream source, and what tool is most suitable? Unusual requirements: * We have substantial 'DFSG' patches to the upstream source * For some upstream versions we have extra 'featureset' patches that are only applied for some builds => git-dpm is OK with DFSG-patches to upstream, not with featuresets => git-dpm not very good for multiple maintainers => git-buildpackage can switch between quilt and commit series, and invoke git rebase when updating upstream; not sure about DFSG-patches Building with Python 3 ====================== Python 3.4 is in jessie and sid. Most of our Python scripts should be ready for Python 3. Time to switch? => looks like it