{"action":"created","issue":{"url":"https://api.github.com/repos/openSUSE/openSUSE-release-tools/issues/1630","repository_url":"https://api.github.com/repos/openSUSE/openSUSE-release-tools","labels_url":"https://api.github.com/repos/openSUSE/openSUSE-release-tools/issues/1630/labels{/name}","comments_url":"https://api.github.com/repos/openSUSE/openSUSE-release-tools/issues/1630/comments","events_url":"https://api.github.com/repos/openSUSE/openSUSE-release-tools/issues/1630/events","html_url":"https://github.com/openSUSE/openSUSE-release-tools/issues/1630","id":346767272,"node_id":"MDU6SXNzdWUzNDY3NjcyNzI=","number":1630,"title":"repo_checker: proposal to abandon project level whitelist","user":{"login":"jberry-suse","id":22943929,"node_id":"MDQ6VXNlcjIyOTQzOTI5","avatar_url":"https://avatars2.githubusercontent.com/u/22943929?v=4","gravatar_id":"","url":"https://api.github.com/users/jberry-suse","html_url":"https://github.com/jberry-suse","followers_url":"https://api.github.com/users/jberry-suse/followers","following_url":"https://api.github.com/users/jberry-suse/following{/other_user}","gists_url":"https://api.github.com/users/jberry-suse/gists{/gist_id}","starred_url":"https://api.github.com/users/jberry-suse/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jberry-suse/subscriptions","organizations_url":"https://api.github.com/users/jberry-suse/orgs","repos_url":"https://api.github.com/users/jberry-suse/repos","events_url":"https://api.github.com/users/jberry-suse/events{/privacy}","received_events_url":"https://api.github.com/users/jberry-suse/received_events","type":"User","site_admin":false},"labels":[{"id":78781492,"node_id":"MDU6TGFiZWw3ODc4MTQ5Mg==","url":"https://api.github.com/repos/openSUSE/openSUSE-release-tools/labels/enhancement","name":"enhancement","color":"0e8a16","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2018-08-01T21:01:02Z","updated_at":"2018-08-03T00:53:54Z","closed_at":null,"author_association":"COLLABORATOR","body":"Based on my thinking for some time and the desire for stacking the repo chain in #1624 which exposes this issue more directly it seems now may be the time to make a change.\r\n\r\nCurrently, there exists two levels to the `repo_checker` whitelist.\r\n\r\n1) target project (in `:Staging/dashboard/config/repo_checker-binary-whitelist*`)\r\n2) staging project (project psuedo-meta set via `osc staging config repo_checker-binary-whitelist*`)\r\n\r\nThe second only applies to the staging project on which it is set and the target project is applied to all.\r\n\r\nThe whitelist was introduced when I rewrote the `repo_checker` to look at staging projects instead of devel project binaries. The previous approach directly inserted an individual or group of package container binaries into the solv information for the target project. This had the benefit of automatically scoping to only the packages being changed, but would miss problems occuring due to rebuilds and such occurring in staging, not to mention missing everything that happened in staging since it didn't look at it.\r\n\r\nThe new design reviewed a staging project as a whole, but this also meant it was unclear which problems were \"known\" or \"pre-existing\" and which were caused by the changes in question. As such the whitelist was introduced to _acknowledge_ problems that were _known_ to be in the target project. The assumption was the problems would eventually reduce down to near nothing which was true, but given the staging projects only cover ring packages or the packages being changed (adi) a large number of existing problems never had to be placed in the whitelist.\r\n\r\nThe alternative approach I had envisioned, which I think is theoretically closer to what you want, is to diff the result of the staging project as if it was accepted and part of the target project (ie everything) and diff against the output from the target project to see what is new. Based on the assumption that the problems in the target project would be kept minimal as they are undesirably and considered problems it seemed the whitelist approach as a initial phase tool was far simpler (and it was).\r\n\r\nDiffing is a bit complex due to very subtle changes making waves in the solver output and of course any rebuild changing all the numbers. I later added `install_check_parse()` which parses the output to determine the packages involved. This was used to compute a hash to avoid spamming essentially the same comment on packages in devel projects caused by rebuilds.\r\n\r\nThe same function was later used to automate removing unnecessary entries from the whitelist in `install_check_parse()`. Essentially, if we boil the whitelist down to:\r\n\r\n> Everything that made it past staging and into the target project is a known issue.\r\n\r\nThat can be entirely automated now. This means, during the `project_only` mode the whitelist could be generated by a slight tweak to `whitelist_clean` and thus becomes a \"_cache_ of binary names involved in solver problems\". At which point it could just be cached locally or computed every time `repo_checker` runs based on the latest `project_only` output in `:Staging/dashboard/repo_checker`. \r\n\r\nEffectively, removes the level 1 whitelist and leaves only the staging project whitelist. This would then allow non-filtered/scoped reviews of staging projects as if they were part of target project and effectively diffed against target project. The caveat (which already exists) based on the nature of the whitelist is that new issues involving binaries with existing issues will be ignored. This is outside the base-scope of this problem and can be solved separately by a more detailed parsing of solver output or using some more direct communication with solver to acquire structured data.\r\n\r\nThis also makes usage of the `repo_checker` for devel projects much more useful since one could review an individual request against devel project and automatically ignore existing issues since no one to maintain the whitelist. Plus staging masters no longer have to deal with it.\r\n\r\nAssuming no one opposed I will implement this before #1624 since it can be done independently and then we can merge that without wreaking havoc in Factory."},"comment":{"url":"https://api.github.com/repos/openSUSE/openSUSE-release-tools/issues/comments/410111177","html_url":"https://github.com/openSUSE/openSUSE-release-tools/issues/1630#issuecomment-410111177","issue_url":"https://api.github.com/repos/openSUSE/openSUSE-release-tools/issues/1630","id":410111177,"node_id":"MDEyOklzc3VlQ29tbWVudDQxMDExMTE3Nw==","user":{"login":"jberry-suse","id":22943929,"node_id":"MDQ6VXNlcjIyOTQzOTI5","avatar_url":"https://avatars2.githubusercontent.com/u/22943929?v=4","gravatar_id":"","url":"https://api.github.com/users/jberry-suse","html_url":"https://github.com/jberry-suse","followers_url":"https://api.github.com/users/jberry-suse/followers","following_url":"https://api.github.com/users/jberry-suse/following{/other_user}","gists_url":"https://api.github.com/users/jberry-suse/gists{/gist_id}","starred_url":"https://api.github.com/users/jberry-suse/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jberry-suse/subscriptions","organizations_url":"https://api.github.com/users/jberry-suse/orgs","repos_url":"https://api.github.com/users/jberry-suse/repos","events_url":"https://api.github.com/users/jberry-suse/events{/privacy}","received_events_url":"https://api.github.com/users/jberry-suse/received_events","type":"User","site_admin":false},"created_at":"2018-08-03T00:53:54Z","updated_at":"2018-08-03T00:53:54Z","author_association":"COLLABORATOR","body":"> can e.g. right away spot what repository the problematic packages come from (and elimate their versions and architectures).\r\n\r\nSure, but not that simple since the list of packages involved in such chains may changes in interesting ways which makes normalization difficult at least to decide what constitutes a changes that a human would want to see.\r\n\r\n> hmm. i wonder if pkglistgen and repochecker could share code or are actually just different modes of operation of the same program.\r\n\r\nSimilar definitely, the mirror and such already has an issue to share that code, but the preparation like groupings from staging and such is different and output obviously. Could probably share more than they do."}}
{"actor":{"display_login":"jberry-suse"}}