Ubuntu Wiki

Kernel SRU Workflow (proposed)

The kernel release tracking bug is going to be changed to facilitate better communication between the responsible parties and clearer handoffs as the release progresses.

We are taking advantage of existing Launchpad capabilities.

"[skaet - but we will need to refine/adjust the definition of bug status to suit the task semantics, so probably need to not gloss over this. ]"

When a kernel release tracking bug is created, it is created against the relevant kernel source package and nominated for the related Ubuntu series. The new process will target the bug against an additional project, the "Kernel SRU Workflow" project and nominate it for all the series that are defined for that project.

The "Kernel SRU Workflow" project has a number of custom "series" created for it that represent the different stages of the kernel cadence. A "series" represents a task to be accomplished by a team/person. The different tasks will be assigned to the team/person responsible for that stage. The assignee will set the status of the tasks they are working.

"[skaet - also suggest mentioning that the tracking bug will be flagged in the http://kernel.ubuntu.com/~kernel-ppa/reports/sru-report.html with a star, and to go there to check the overview status of the various kernel drops.]"

An automated script will run periodicaly to monitor the current state of the different tasks and change status when necessary. This script will be referred to below as the Workflow Mgr. The kernel team will develop this bot.

The Workflow:

1. The kernel team creates a tracking bug, all tasks will be set to their initial state (status: Incomplete) and be assigned to the appropriate team.

"[skaet - why was Incomplete chose over new? new seems closer to the actual semantic meaning across all the states at the start? ]"

1. The kernel team sets the Prepare-package task to the in-progress state (status: In Progress)

"[skaet - would it make sense at this point to change the assignee from the team to the person who is actually working on it, so if there are questions, we can be more efficient?]"

1. The kernel team builds and uploads the source package to the kernel team ppa. Once the source package successfully builds and is ready to be copied to proposed the task state is changed to completed (status: Fix Released).

2. Workflow Mgr. detects that the state of the Prepare-package task has completed and changes the Promote-to-proposed task to its ready-to-start state (status: Confirmed).

3. An archive admin sets the Promote-to-proposed task to in-progress (status: In Progress) and copies the package to the proposed pocket in the archive.

4. Once the package has been copied an archive admin sets the Promote-to-proposed task to completed (status: Fix Released).

"[skaet: s/archive admin/stable release team member/, and person doing the setting should probably explicitly change the owner from the team to self ]"

1. Workflow Mgr. detects that the state of the Promote-to-proposed task is now completed and changes the state of the Verification-testing task to the in-progress state (status: In Progress). (Affected bugs are marked for verification needed)

2. Once all the bugs, requiring verification, listed in the changlog have been marked verification-done, the Workflow Mgr. changes the state of the Certification-testing, Regression-testing and Security-signoff tasks to the ready-to-start state (status: Confirmed).

3. When the HW Certification team detects that the Certification-testing task is in the ready-to-start state (status: Confirmed) and they start testing, they change the tasks state to in-progress (status: In Progress).

"[skaet: again probably a good thing to make sure who is doing the work (or focal point) is indicated directly]"

1. When the QA team detects that the Regression-testing task is in the ready-to-start state (status: Confirmed) and they start testing, they change the tasks state to in-progress (status: In Progress).

2. When the security team detects that the Security-signoff task is in the ready-to-start state (status: Confirmed), they take care of any tasks they deem necessary prior to having an archive admin copy the release to the security pocket. If there are no CVEs, the security team sets the Promote-to-security task to the not-needed state (status: Invalid). If there are CVEs in the release and the security team has signed-off on the release being promoted to the security pocket (once all testing passes successfully) they change the status of the Security-signoff task to completed (status: Fix Released).

3. Once certification testing completes, the HW certification team changes the state of the Certification-testing task to completed (status: Fix Released). If the testing was successfull the certification team adds a certification-testing-passed tag otherwise they add a certification-testing-failed tag.

4. Once regression testing completes, the QA test changes the state of the Regression-testing task to completed (status:Fix Released). If the testing was successfull the QA team adds a qa-testing-passed tag, otherwise they add a qa-testing-failed tag.

5. When both the Certification-testing and Regression-testing tasks have been set to completed states (status: Fix Released) and both the certification-testing-passed and qa-testing-passed tags have been added by the appropriate team, the Workflow Mgr. changes the state of the Promote-to-updates task to the ready-to-start state (status:Confirmed).

6. An archive admin copies the package from proposed to the updates pocket in the archive and sets the Promote-to-updates task to completed (status: Fix Released).

"[skaet: s/archive admin/stable release team member/]"

1. If the Promote-to-security task is set to the ready-to-start state(status: Confirmed), an archive admin copies the package to the security pocket and sets the state of the Promote-to-security task to completed (status: Fix Released).

Note: Some tasks can move from Confirmed straight to Fix Released depending on the amount of time/effort involved in the task.

"[skaet: has anyone already created flow matrix with the above tasks, and cross check that all of the status below has useful meaning in each of the contexts? Maybe supplement this with a flow diagram? with states illustrating transition work flow, at each stage show the expected state of each of the tasks? (complete with named assignment, and status), BUT lots of work though... yuck. not sure. I get a feel for where this is going it, and generally the right thing to do but don't think it handles the failure cases - when things get marked Invalid - what happens. So we should probably spell it out, and save ourselves alot of fustration and cross threading, because if someone can misunderstand, they will (and they won't read this throughly to boot, adding pictures will reinforce ) ]"

An Example Tracking Bug

https://bugs.launchpad.net/kernel-sru-workflow/+bug/677021

Tasks

"[skaet: suggest putting links to the actual teams launchpad pages, so there is no ambiguity, and a quick way to mail out to the relevant team when question. Also, it should be the Stable Release Team, not the Archive Admin Team - its actually an intersection of both teams, but the Stable Release Team is smaller and knows what to do, general archive admins can't do what needs to be done...]"

Status