Without this, python 3 execution will fail with:
TypeError: Unicode-objects must be encoded before hashing
The requests strategy is the only strategy to utilize kwargs besides
custom so this code is not executed often which is why this has not been
encountered. In fact it was executed mistakenly and reported.
Python 3 makes map() a lazy call and since the result is not needed it
makes sense to just switch to explicit loop. Without this the "loop" (via
map) is never executed. As such, --try-strategies effective does nothing
and instead the staging-bot always falls back to none strategy.
Without this, the relative rarer types of requests seen in projects with
staging and handled by list command will be included in staging proposal.
However, since they are not stageable the select operation will fail. This
change ensures that a filter is always present when stageable is True to
exclude non-stableable requests. The list command sets stageable to false
in order to list out the non-stageable requests of interest.
This was not observed in openSUSE since the main non-stageable request was
change_devel and that was exluded in StrategyNone. That filter could be
replaced with the stageable filter, but having an always on filter seems to
make more sense since generally operating in one of two modes.
The addition of factory-auto and repo-checker reviews need to be allowed
since they are always present and do not constitute a non-quick review.
In an attempt to future proof the strategy the allowed review groups are
taken from the project configuration and repo-checker from config.
Using build percentage is sub-optimal since many events can reset the
percentage which can result in additional requests being merged into the
staging. A better metric is the time since the first request was added to
the staging (the age of the staging). Unfortunately, this is not trivial to
determine especially given that the original request may be superseded or
unstaged entirely. As such the datetime at which the staging was activated
is stored in the staging pseudometa. A max age is then used to allow for
merging up until that point.
- reworked internal representation of stagings to be more flexible
- new considerable staging state of mergeable based on set of conditions
- multiple proposal stages can be combined to create one proposal
- proposals may now fail to find every group a home without stopping
- splitter_info is stored when first request in an empty staging is staged
to allow for automated merging into that staging
- strategy concept introduced along with several strategies
- strategy_try() concept for applying multiple strategies and keeping
desirable groups which provides a solid basis for making smart decisions
- merge() introduced for merging new requests into existing stagings
- various internal cleanups along the way
functionality exposed via osc-staging:
- new options: --merge, --try-strategies, --strategy
- splitter info written when not merging
stagingapi: add set_splitter_info_in_prj_pseudometa().
