----------------------------------------------------------- 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 > >
_______________________________________________ qa-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/qa-devel
