From Fedora Project Wiki
< Changes | Two Week Atomic
Responsibility Matrix for the Two Week Atomic Fedora Change
This is a RACI matrix for tasks required to implement Two Week Atomic. Work is tracked in Taiga: http://taiga.cloud.fedoraproject.org/project/acarter-fedora-docker-atomic-tooling/wiki/home
Is this current?
It is, as of 2015-08-27.
Definitions
Here, we're using what Wikipedia calls "RACI (alternative scheme)":
- Responsible
- The person responsible for the performance of the task. There should be exactly one person with this assignment for each task. People in the Assists column for the overall task may be Responsible for subtasks, but it's the top-level Responsible person's job to make sure those subtasks do not get blocked.
- Assists
- Those who assist completion of the task. For small tasks, may be "—".
- Consulted
- Those whose opinions are sought; and with whom there is two-way communication.
- Informed
- Those who are kept up-to-date on progress; and with whom there is one-way communication.
Task Table
This an early cut. Please feel free to add new tasks as appropriate — just let one of the coordinators know.
Kanban!
We'll keep the main tasks here, but the subtasks will probably be replaced with a Kanban board on our taiga site
We'll keep the main tasks here, but the subtasks will probably be replaced with a Kanban board on our taiga site
| Task | Subtask | Responsible | Assists | Consulted | Informed | Current Status |
|---|---|---|---|---|---|---|
| Update koji for nightly image builds | ausil | maxamillion | mattdm, jkurik | 0% | ||
| script run from cron nightly | mattdm | 100% | ||||
| update script for installer iso | " | 100% | ||||
| better implementation with pungi4 (non-blocker) | " | 0% | ||||
| trigger on compose rather than on a timer (non-blocker) | " | 0% | ||||
| only build if contents change (non-blocker) | " | 0% | ||||
| Create automated test system | kushal | QA, mattdm, jkurik | 0% | |||
| listener for successful builds | mattdm | 0% | ||||
| automatic test execution | " | 0% | ||||
| basic smoketests functional (deeper testing desired, but out of scope here) | jasonbrooks | mattdm, QA | 0% | |||
| ability to run non-gating advisory tests (optional) | mattdm | 0% | ||||
| results to fedmsg | " | 0% | ||||
| results dashboard | " | 0% | ||||
| mechanism to mark a build as bad even if automatic tests pass | " | 0% | ||||
| mechanism to mark a build as bad even if automatic tests pass | " | 0% | ||||
| migrate to taskotron instead of tunir, when tasktron is ready (non-blocker) | " | 0% | ||||
| Create automatic bug management system | mattdm, jkurik | 0% | ||||
| file bugs for build, test, or release failure | " | 0% | ||||
| on subsequent failures, update bugs with comments | " | 0% | ||||
| on success, close bugs | " | 0% | ||||
| Create automatic release system | maxamillion | mattdm, jkurik | 0% | |||
| every two weeks, scan for images which pass all tests | " | 0% | ||||
| integration with fedimg | " | 0% | ||||
| upload to alt.fpo (or main mirrors?) | " | 0% | ||||
| automatically update website | " | 0% | ||||
| email announcement | jzb | " | 0% | |||
| fallback mechanism for no builds in two weeks | " | 0% | ||||
| Create new website | jzb | mattdm, jkurik | 0% | |||
| decide on location (stand alone, still part of getfedora.org, or labs.fpo) | jzb | Cloud WG, Design Team, Websites | mattdm | 0% | ||
| site design | jzb | 0% | ||||
| new copy (introduction, documentation, disclaimers) | jzb | jasonbrooks | 0% | |||
| new artwork | jzb | 0% | ||||
| site implementation | jzb | 0% | ||||
| changes to getfedora.org as/if appropriate (crosslinks, etc.) | jzb | 0% | ||||
| Trademark approval | mattdm | — | Council, jzb | Other change owners, jkurik | 100% | |
| for use of Fedora Atomic Host | mattdm | — | Council | Other change owners | 100% | |
| possibly for new artwork (optional) | mattdm | — | Design, Council | Other change owners, Websites | (not yet required) | |
| Overall communication and coordination | mattdm | jzb | Cloud SIG, upstream Project Atomic, Release Engineering, Websites, Design | FESCo, jkurik | 10% | |
Glossary of Nicknames
- ausil Dennis Gilmore
- jkurik Jan Kuřík
- jzb Joe Brockmeier
- kushal Kushal Das
- mattdm Matthew Miller
- maxamillion Adam Miller
- walters Colin Walters
Various Task Notes
- If we get to the point of only building images when there are changes to the content set, that process still needs to notify the testing process that no build was generated on purpose rather than due to failure, and that then trickles down to the automatic release process in the (unlikely, but theoretical) possibility that nothing changes in the content set for two whole weeks.
- I'm imaging the "manual override" to be a command that authorized users can run to put a message on the fedmsg bus declaring a certain build to be bad (or possibly good), and this would override any automatic test results for an image with a matching name. (Possibly only automatic test results with an earlier timestamp? Mattdm (talk) 23:21, 18 June 2015 (UTC)
- Assuming the bug tracking system here is Bugzilla, we'll need Bugzilla actually set up for this. That means either setting up a new Component for each image type we create in the main Fedora bugzilla product, or creating a new bugzilla product. That could be "Fedora Atomic", but it might be better for it to be "Fedora Images" (keeping the main product's components mostly corresponding to RPMs).
Schematic
