From Fedora Project Wiki

(Initial write-up, based on our conversation with dgilmore)
 
m (Add to the releng category)
Line 18: Line 18:


QA could request Test Composes through a proper form in Compose DB rather than through a Trac ticket. This could even start parts of the process automatically. (up until a human needs to sign?)
QA could request Test Composes through a proper form in Compose DB rather than through a Trac ticket. This could even start parts of the process automatically. (up until a human needs to sign?)
[[Category:Release Engineering]]

Revision as of 13:52, 18 August 2014

Note.png
This is a draft
Fedora Releng wants a compose database. This page lists the ideas behind it and its potential features.

Goal

The primary goal is to make Releng work more transparent, by tracking everything Releng produces (composes, update pushes) across all releases (current, pending and Rawhide), and all architectures. (primary and secondary)

Primary Features

We want to be able to easily tell, at all time, what exactly was produced. (the NEVRA of all packages, the keys used to sign each one of them, the size of the isos,...)

Knowing how each was produced would also be very good to have. (the versions of the compose tools, the kickstart used to create it, ...)

Finally, we want to be able to easily diff two composes, to quickly identify changes. (for example, to figure out why TC2 is oversized while TC1 wasn't)

Ideas

The current process to compose Fedora uses the run-pungi script. This script could be made to upload its results to the Compose DB.

QA could request Test Composes through a proper form in Compose DB rather than through a Trac ticket. This could even start parts of the process automatically. (up until a human needs to sign?)