> I currently don't have a use case for a run against multiple archives,
Yes, you do - Matthias, you need to explicitly include the primary archive when checking, this is why svammel filed bugs for you against already-superseded build failures in the test archive. :-)
But yes, I think this is something that's good to have. Also, setting an importance for the bug would help a lot with automation - should this be a separate bug report?
What should the behavior be when setting these attributes fails due to access control? I.e., if someone who's not a core-dev runs this script, they can't target to a series AFAIK; should the script abort at the first error then? should it rollback the freshly opened bug report that it can't set the requested state on (i.e., close the bug)?
> I currently don't have a use case for a run against multiple archives,
Yes, you do - Matthias, you need to explicitly include the primary archive when checking, this is why svammel filed bugs for you against already-superseded build failures in the test archive. :-)
But yes, I think this is something that's good to have. Also, setting an importance for the bug would help a lot with automation - should this be a separate bug report?
What should the behavior be when setting these attributes fails due to access control? I.e., if someone who's not a core-dev runs this script, they can't target to a series AFAIK; should the script abort at the first error then? should it rollback the freshly opened bug report that it can't set the requested state on (i.e., close the bug)?