From Fedora Project Wiki

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:

Is this current?

It is, as of 2015-09-25.


Here, we're using what Wikipedia calls "RACI (alternative scheme)":

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.
Those who assist completion of the task. For small tasks, may be "—".
Those whose opinions are sought; and with whom there is two-way communication.
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.
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 100%
script run from cron nightly mattdm 100%
update script for installer iso " 100%
better implementation with pungi4 (non-blocker) " DROPPED
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 100%
listener for successful builds mattdm 100%
automatic test execution " 100%
basic smoketests functional (deeper testing desired, but out of scope here) jasonbrooks mattdm, QA 100%
ability to run non-gating advisory tests (optional) mattdm 0%
results to fedmsg " 100%
results dashboard " 100%
mechanism to mark a build as bad even if automatic tests pass " 100%
migrate to taskotron instead of tunir, when tasktron is ready (non-blocker) " (Not ready / dropped)
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 80%
every two weeks, scan for images which pass all tests " 75%
integration with fedimg " 100%
upload to alt.fpo (or main mirrors?) " 100%
automatically update website " 50%
email announcement jzb " 100%
fallback mechanism for no builds in two weeks " 50%
Create new website jzb mattdm, jkurik 0%
decide on location (stand alone, still part of, 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 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

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)
    • this same mechanism could also be used to label certain images as special in some other way (for example, for non-atomic images, to mark certain nightly builds as RCs or gold composes) 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).