On Jan 29, 2009, at 4:12 PM, Benson, Channing D wrote: > Please read and comment. > > http://fossology.org/task:buckets
I don't think of REGEX, SCRIPT, ... as "bucket types". Like you said, this are simply methods that can be invoked to determine what goes into what bucket. It would be good to give some examples to highlight the use of buckets and sets of buckets. For example: I could define a set of buckets (a bucket brigade?). I'll call the set "FSF buckets". I create rules using REGEX, SCRIPT, etc for populating individual buckets "GPL Compatible Free Licenses", "GPL Incompatible Free licenses", "GPL incompatible licenses", and "unknown". Now, when I get a license report, and "FSF buckets" is selected, all the licenses are reported in terms of these 4 buckets. Another example, I could define a set of "What Changed" buckets. Here the definition would be for two buckets, "Changed" and "Not Changed". Any packages with different licenses than the previous version, would go into "Changed" and those that did not change would go into "Not Changed". This would make it easy to check if any packages changed their license terms. You asked which "bucket types" are redundant but didn't define them. Here is how they are defined: # DEFAULT (the default destination, can only be specified ONCE) # STR-FILE (test entire license against strings in a file, match ENTIRE line) # PATT-FILE (test entire license against regex list in a file) # COMP-FILE (test license components against lines in a file) # SCRIPT (execute shell-script, passed env-vars describing license) # EXEC (execute program, passed env-vars describing license) # REGEX (test entire license against a regex) # STRING (compare entire license against a string) I'm not sure if there is really a difference between EXEC and SCRIPT, but I don't think any of the others are redundant. I like EXCLUSIVE and COMMON. Although, I think I'd use NONEXCLUSIVE instead of COMMON. I think you should end up in the DEFAULT bucket in COMMON mode if you don't end up in any other bucket. An elegant hierarchy? All I see is a collection of bucket sets. Each set, like FSF buckets above, contain a flat list of buckets. I like the idea of a tree of buckets but I don't think we have a real use for it at the moment. Is that what you meant? Buckets would get invoked just like any other agent. When you upload something to the repo, you decide what agents should run. Or you can use Jobs > Agents. On "Bucket Contents and Domain", you communicate parameters to the bucket agent in jobqueue.jq_args. See an agent UI plugin for an example. You can put whatever text info you want into jq_args. Agents usually operate on "uploads". You might upload an iso, tar, bz2, single file, whatever and the upload_pk would be passed to the bucket agent. In addition to the upload_pk, you would want to know which bucket sets you should analyze for (or ALL enabled bucket sets). You might also want to know what to do if the bucket agent for set X has already run on some files of this upload. You would want to know if you are forcing the bucket agent to rerun or if it should ignore the files that have already been analyzed (the latter would be typical). You probably also want to implement a "bucket sets available" and "bucket sets enabled". That way we can ship some interesting sets (shipped but not enabled) that people can easily turn on if they wish. Bob _______________________________________________ fossology mailing list [email protected] http://fossology.org/mailman/listinfo/fossology
