Jimmy Berry wrote:
In order to finish things up in regards to the repo checker (#964) [1] 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 handling - #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 letter stagings.
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 after all.
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. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner@opensuse.org