Ubuntu Wiki

• Launchpad Entry: kernel-o-kernel-sru-state-of-the-cadence

• Created: 2011-04-05

• Contributors: Brad Figg, Steve Conklin

• Packages affected: None

Summary

For the Natty series, the Kernel SRU Team and related stakeholders moved to a two week cadence for producing kernel packages, having the affected bugs verified and getting the packages tested. There were some growing pains along the way as to be expected. However, by midway through the Natty development cycle the process is moving along pretty well.

The purpose of this specification and associated UDS session(s) is to layout what the Kernel SRU Team has identified as issues and is working on solutions for. It is also for other stakeholders to identify areas in the process that they would like to see addressed.

Release Note

This has no impact on the release notes.

Rationale

Need to refine and improve the Kernel SRU Cadence in order for it to be easier to work with for all involved.

Issues

1. During the cadence, transitions from team to team are neither smooth nor automated. This can lead to questions about what is happening with packages at different times in the cadence. Who is waiting on whom, etc.
   • A proposal was put out on a new way to handle automated transitions using the tracking bugs, a special LP project and custom series.

     • See: Kernel SRU Workflow

   • The bot that runs against these new tracking bugs has been developed and is being tested. We will begin running this in production, post-UDS-O.
2. There has been a little confusion due to the cadence transition dates being on Thursdays. It's clear that this lines up in a fashion with the development releases being on Thrusdays but from observation and experience with the cadence, though transitions may happen on Thrusdays, actual work does not start until the following Mondays. It is felt that it makes sense to change the cadence transitions to happen on Mondays. The cadence validation will start on a Monday, the regression / certification testing will start on the following Monday, etc.
   • The Natty Interlock schedule had new cadence cycles starting on Thursdays. Going forward, cycles should start on Mondays.
3. It is unclear to many folks that don't deal with the cadence cycles on a regular basis, when the next cycle starts. We get asked this fairly regularly.
   • A public, google calendar will be maintained which clearly spells out when upcoming cycles start and end.
4. Consider possible changes to the length of the cadence
   • The current cadence is a two week cycle. The first week is bug verification. The second week is regression and certification testing. The regression and certification testing can take the entire second week to complete for all the relevant packages. Because of this and the need to start the next cycle as soon as regression and certification testing is complete, it is necessary for the Kernel SRU Team to put all their packages together several days before the testing has completed.
   • A longer cycle would allow the Kernel SRU Team to put together and build the packages for the following cycle.
5. Other issues related to cadence
   • With frequent releases , users need to download the large kernel packages more often

     • See Bug: Accumulating kernels is cruel and unusual punishment

   • Unless users manually clean up, old kernels are not purged from their systems

BoF Agenda and Discussion

• Go through each of the issues.
• Open the floor for issues that other stakeholders have with the cadence or any of the new proposals.