= Depcheck workflow =
After discussing some issues with Kamil, we decided, that it would be for the best, if we wrote down the intended Depcheck results usage & workflow.
The problem is tightly connected to #306. The problem described in #306 means this:
== Premise ==
"Updates can be changed in Bodhi." - the evidence is clear https://admin.fedoraproject.org/updates/control-center-3.0.0-1.fc15,gnome-settings-daemon-3.0.0.1-1.fc15, if you look at the bodhi comment from 2011-04-06 15:05:38 "hadess has edited this update..."
== Implications ==
=== Timeline ===
1) All updates in -pending passed depcheck, and have "PASSED" comment. 2) Update XYZ is changed by the developer
=== Consequences ===
Because one of the "already passed" updates is changed, we should discard the whole "passed" subset, because we can not be sure, that some errors were not introduced by the change.
== Level 1 Solution ==
#306 describes the 'simple' solution. When we search for the 'accepted' updates, we look for all the updates, which do have "PASSED depcheck" comment in bodhi.
We want to detect, whether the update was changed after the "PASSED depcheck" comment, and if so, then remove it from accepted set, and basicaly retest it.
== Level 2 Solution ==
Level 1 solution does not really solve the problem, as described, even though it is certainly needed to detect the 'passed but changed', and will sort out some of the problems.
The problem with the fact, that change in one update can possibly break some 'previously passed' dependency problems is still there.
Because it would be incredibly hard to detect just the updates influenced by changes in the respective update, we decided to define a workflow, which bypasses the overall need for this.
=== RelEng workflow ===
At the moment, rel-eng is pushing updates manualy few times a week [citation needed, this is informal information which has not been audited].
The thing is, that we can provide the _at the moment 'pushable'_ subset of packages. When rel-eng will want to push from -pending to {stable, updates, ...}, they'll just 'list' the pushable subset (yes, resultsdb will help ;-)).
"The tool" will detect if there were any changes in the pushable subset, and "the tool" will inform rel-eng that they either need to wait for the results of the next depcheck run, or (if we're able to do it) request new depcheck run.