Jimmy Berry wrote:
In order to finish things up in regards to the repo
checker (#964)  I will
summarize the situation in the hopes of agreeing on a path forward.
Thanks for the work and summary! It indeed finds issues we didn't see
before. Unfortunately the file conflicts it finds are too late to fix
for 42.3. We certainly need that bot for all future products. Also,
maintenance should use it.
- #973: repo_checker: speed up reviews by comparing has of staging project psuedometa
- #974: repo_checker: invoke mirror, cycle, and install checks in parallel
- #978: repo-checker.pl: detect/handle corrupt package snippet and general error
- #979: repo_checker: cycles discussion
- #980: repo_checker: include non-targeted package messages from installcheck
The last two are the primary issues of interest. The cycles difference should
not be too common and has a set of pros and cons associated with the changes.
The primary blocker is the the inclusion of all installcheck/fileconflict
problems from letter stagings. This change is again beneficial in detecting
problems encountered by more complex packaging, but does not pass for both
Leap:42.3 nor Factory. I have sent a number of SRs to resolve some of the
issues, but the rest need to be resolved before the new repo checker will accept
My suggested path forward would be to continue making the fixes rather than
relaxing the check and resume the freezing of old repo checker. Max had
mentioned the AppArmor profile was relaxed/disabled which would be good to
confirm. I will likely look around on packagelists and make the change again.
I agree that we need to fix the issues it finds, they are valid
The last minor discussion point is that the ReviewBot
currently operates either
on a project + request type or reviews targeting a user/group. The current repo
checker uses the user/group target, but that would mix reviews for Factory and
Leap in one cycle. The ReviewBot could be changed (or extended) to allow
Is there a problem with processing all requests in the same bot
instance? If we wanted to use different instances we could also use
different users instead. Is the new bot faster then the old one?
filtering by project in addition to review target or
all reviews could be run in
the same cycle (same service on packagelists).
Using the project method would need to be tweaked to allow for multiple request
types (as currently it has to be run twice, once for submit and once for
delete), but that method currently includes already reviewed requests which adds
to clutter the repo checker has to dig through.
Adding the project filter to review target method likely makes sense, but
perhaps there are some unintended side-effects to other bots?
I don't mind adding more complex modes of operation, the existing
ones should continue to work though to avoid breaking other bots.
(o_ Ludwig Nussel
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-releaseteam+owner(a)opensuse.org