Decide how tests for proposed kernels will get done. Where results will be available and how we proceed in case of problems.

Release Note



In order for upstream stable changes being better checked for possible regressions we need to have testing of proposed kernels on a bigger hardware base. If anything breaks there, we need to have some process defined to make the kernel-team aware of those issues and prevent the proposed kernel to go to updates.


  • Uploading to proposed will trigger regression testing.
  • Failures get reported
  • Proposed kernels will not go to updates as long as there are failures.


Test Procedure

  • Define the set of hardware and the testing procedure used. Probably for the beginning only boot and installation tests. Some ideas there:
    • Make it simple to add tests. For example could run the qa-regression tests from the bzr branch.
    • Maybe crazy but could it be open, so people could contribute by running things on private HW?
  • Where are we now?
  • What steps are needed to get where we want to be? Short term and long term.

Test Results

  • What is the output of the tests?
  • Where does it go to?
  • What form?
  • How detailed?
  • Automatically file bugs?
  • Notification system? (subscribe to get results when there are regressions)


This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.


KernelTeam/Specs/KernelNattyStableProposedTesting (last edited 2010-10-20 13:28:47 by p5B2E55DA)