8fa2e47 Filter bugs harder in the compose/push request templates

Authored and Committed by adamwill 4 years ago
    Filter bugs harder in the compose/push request templates
    
    There were a few issues affecting the 'requests' tab.
    
    First, the underlying queries had a slight bug: they filtered
    the updates by milestone, then further filtered by whether any
    bug associated with the update was an accepted blocker or
    accepted FE. But this is wrong for the case where an update is
    associated with Beta milestone because of a *proposed* blocker
    or FE, and also fixes an *accepted* blocker or FE for Final:
    the queries would return the update in this case, where they
    should not. The blocker query also included accepted_prevrel
    bugs, when it probably shouldn't: prevrel blockers should be
    fixed in previous releases, not the Branched release. An update
    for Branched marked as fixing an AcceptedPreviousRelease bug
    is probably a mistake, and we shouldn't include it in this
    query or the stable push/compose requests.
    
    Second, when generating the list of bugs that each update would
    resolve, the requests.txt template itself just iterated over
    all bugs associated with the update, without considering their
    milestone or whether they were accepted. So it includes Final
    blocker/FE bugs in the list for a Beta request, if the update
    fixes any, and it also includes proposed blockers/FEs if the
    update fixes some of those along with accepted blockers/FEs.
    That's wrong. This is not very important - the list is only
    informational - but it is incorrect and confusing, so we should
    fix it.
    
    We enhance the tests to cover some of this. It doesn't cover all
    possible scenarios - that'd get pretty messy without a heavy
    rewrite of this stuff using parametrization or something - but
    it's definitely better.
    
    Signed-off-by: Adam Williamson <awilliam@redhat.com>
    
        
file modified
+81 -14