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
signature.asc
Description: PGP signature
