Otherwise, requests that are declined quickly (likely by bot) are not
shown in history which can be confusing when viewing in web interface. A
package may show as being one revision behind and one would wonder why
not update request when in fact a request could have been made and
declined.
As a follow-up to new packages accepted from a specific devel generate
a change_devel request automatically. Such requests should be approved
automatically since they are a workaround to not being able to set devel
during source submission.
To improve robustness and handle invalid/corrupt data in the annotation
just return None if it is anything other than a dict after parsing. The
most likely occurrence is someone accepts the origin-manager review with
a plain-text message.
This excludes reviews that were added and never reviewed possibly because
the request was rejected before the review could be accepted. In such
cases the comment specified when adding the review will be loaded as the
annotation which is not desirable.
This is the best location to expose the information as the action context
is already available. Alternatively, a lookup function accepting a request
target_project and target_package could perform the equivalent of the
client-side filter operation that is part of the initial search. This also
alleviates additional queries that would be needed later.
This was debated as for SLE this would add some repetition when not
going to match a SLE origin anyway, but it is necessary to stabilize
maintenance origins.
When an :Update project is first created all sources are inherited which
means all the revisions from the top project's source container are
considered. Once an update is provided via a maintenance incident the
inherited sources are no longer presented and instead the only revision
seen is the maintenance update and future updates.
When a new version of Leap is created and all source containers are copied
from the previous version the origin will first be considered :Update of
the previous Leap version, but once a maintenance update is created it
will drop the the non-:Update prior version since the matching revision is
missing. If the update is submitted the origin will flip back to :Update.
In order to avoid this mess always utilize include_project_link=True
which will effective consider the maintenance update as the newest
revision while continuing to consider the inherited revisions.
For SLE, were all projects are stacked this means there will almost always
be 10 revisions to review after the first could releases.
Realistically this is yet another failing of the OBS source control model since
the original source revision available (via inheritance) in the :Update project is
lost after the first update.
Previously, there was no way to distinguish between a None origin and no
origin_info passed in. Using False as default allows the two cases to be
distinguished.
