Hi Sam, Even if I said I'll no longer participate, there are some substantial misunderstandings to correct. On Tue, May 26, 2020 at 04:44:49PM -0400, Sam Hartman wrote: > I think you and Mo are a bit stuck in the ftp-team mindset with the > above. *whenever new or bin-new is triggered, all files are reviewed.* It's designed for people who "review all the files" when the package turns to be NEW. For example, one who is about to upload a NEW package. This aims to speed up a **rigorous** review, instead of a much less rigorous review. Generally reviewing things quickly and carelessly makes the life of every uploader much easier -- but that means more burden for our last shield, ftp team. Again, the specification talks about how the status of files are changed in the status space {"N/A", "outdated", "ACCEPT", "REJECT"}, which is a pure interpretation of the modeling of the process, and it did not say any preference on political stuff such as "when the review should be triggered" -- I have no intention to talk about it. My specification is invariant to the review whatever frequency people prefer. If people prefer to do the review after every git commit, libawsl can be useful. If people prefer to slack off and only do the review when the package has to go through the new queue again, libawsl can also be useful. > But to an outsider, what it sounds like Mo is proposing is that whenever > the salt is changed, review needs to be triggered, even if new would not > be triggered in the current model. Talking about how the file status move in the status space {"N/A", "outdated", "ACCEPT", "REJECT"} does not imply any preference on the frequence of review. Why not take git as an example? "N/A": the user didn't git add <this-file> "outdated": <this-file> has been changed, stage and commit it when user sees appropriate. "accept": <this-file> has not been changed, nothing to do "reject": ? no analogous concept, but it does not matter. When did git urge people to stage files, do commits, or push when it gets unhappy about the modified files and unsynced tree status? Is the git efficiency seriously impacted by "how frequent the user does commits", "how frequent the user does commits"? Similarly, when did libawsl urge people to do the review once the file status has been changed? > My thoughts are that > 1) I think it's worth being clear that you're not proposing increasing > the rounds of new review. No. libawsl is independent and ignorant to the review frequency. It is designed to **help human** when they need to do a review, not designed to **prod or force people** to do review once it gets unhappy. > 2) Long term, having a persistent database of review state might allow > us to have better criteria for when to trigger license review. libawsl can use a persistent database to reduce redundant reviews, as long as the salthash do match. There is no design consideration on given answers to questions such as "when to trigger a review". Whatever the review frequency is, libawsl is invariant and will do its job. > --Sam
Attachment:
signature.asc
Description: PGP signature