----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/64/#review125 -----------------------------------------------------------

Yeah, adding a state that doesn't exist in bodhi is not the best solution but the only other thing I can think of would be to "delete" updates like bodhi does and I think that's a far worse solution since we're already aggregating information in the first place.

To be honest, I don't think bodhi should allow deletion like it does (it causes problems for us and complicates some other releng/admin workflows), but that's not my call.

I just had one question/concern about the code but overall, it looks good.

blockerbugs/util/update_sync.py http://reviewboard-tflink.rhcloud.com/r/64/#comment152

Shouldn't this filter the updates to grab just the ones that aren't obsolete or deleted?

- Tim Flink

On Jan. 8, 2014, 2:10 p.m., Martin Krizek wrote:

---

This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/64/

---

(Updated Jan. 8, 2014, 2:10 p.m.)

Review request for blockerbugs.

Repository: blockerbugs

Description

This will not display updates that are obsolete or irrelevant. After fetching updates from bodhi, the clean_updates method will set status of updates that are in database and not in the fetched updates (are not relevant anymore) to 'deleted'. There seems to be no way to know whether an update in db is still present in bodhi or not. So we mark every update in db as 'deleted' that is not currently an update that fixes a blocker bug. The question is whether we want to mark these updates as 'deleted' and create status that does not exist in bodhi or mark them in other way. If a situation where a 'deleted' update is used again as a fix of a blocker bug occurs, its status is set back to 'testing' or 'stable' on the next update sync. Any suggestions about improving or changing the approach?

Diffs

testing/testfunc_update_sync.py 48dfb500469b8f237020b5d0845ae60a4e1fb776 blockerbugs/util/update_sync.py 47dbc9fa17ed3b751417b4ab822c257fa5423f4b blockerbugs/controllers/main.py 5455e1aa2bbf6edc551223ee6fccb9c6236f0eb8 blockerbugs/__init__.py 3525501c382f21339dab0e18e973141ad29073e3

Diff: http://reviewboard-tflink.rhcloud.com/r/64/diff/

Testing

Unit test attached in the patch. Some testing done on my dev machine as well.

Thanks,

Martin Krizek

----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/64/ -----------------------------------------------------------

(Updated Jan. 15, 2014, 1:19 p.m.)

Review request for blockerbugs.

Repository: blockerbugs

Description -------

This will not display updates that are obsolete or irrelevant. After fetching updates from bodhi, the clean_updates method will set status of updates that are in database and not in the fetched updates (are not relevant anymore) to 'deleted'. There seems to be no way to know whether an update in db is still present in bodhi or not. So we mark every update in db as 'deleted' that is not currently an update that fixes a blocker bug. The question is whether we want to mark these updates as 'deleted' and create status that does not exist in bodhi or mark them in other way. If a situation where a 'deleted' update is used again as a fix of a blocker bug occurs, its status is set back to 'testing' or 'stable' on the next update sync. Any suggestions about improving or changing the approach?

Diffs (updated) -----

testing/testfunc_update_sync.py 48dfb500469b8f237020b5d0845ae60a4e1fb776 blockerbugs/util/update_sync.py 47dbc9fa17ed3b751417b4ab822c257fa5423f4b blockerbugs/controllers/main.py 5455e1aa2bbf6edc551223ee6fccb9c6236f0eb8 blockerbugs/__init__.py 3525501c382f21339dab0e18e973141ad29073e3

Diff: http://reviewboard-tflink.rhcloud.com/r/64/diff/

Testing -------

Unit test attached in the patch. Some testing done on my dev machine as well.

Thanks,

Martin Krizek