On Tue, May 24, 2016 at 16:21 +0000, you wrote:
> Yeah, I have ideas, but seems like there might be another day of some > discussion before I try to formally reframe a design doc. Here’s the > direction I'm thinking: I like the process you sketch, that sounds like the right way to go to me. A few notes, also trying to address some of Adam's comments: > - the initial submission process involves doing a pull request on the > bro/cban repo where the only change made is the addition of a > submodule. These merges probably can be automated, but if a human > were to do it, I’d expect it wouldn’t be a time-consuming task Yeah, maybe that initial merge is one task we leave to a human, who could then actually take a quick 30sec look at the module to see if it's not totally off the mark. That would address Adam's point about what if somebody submits something that's not even a Bro thing (but I wouldn't go further; e.g., don't try to compile, etc.. Everything looking roughly right gets in at this time.) > - submodules that are found to have never been in a working state are > auto-removed (or could initially be a task that’s not a big deal for a > human to do every so often if metrics of brokenness are consistently > available) Auto-removal sounds dangerous to me; there may be different reasons why something's not in a good state. I'd leave cleanup to humans too: if there's a module that's consistently flagged as broken, that's when we can send a mail to the author and remove it manually if no improvement is in sight. I'd rather err on the side of having a broken module than remove something that could actually still be useful. > - metadata logically can be categorized in two types, one type is > related to discoverability (tags, author, license, etc) and one type > is related to interoperability (version number, dependencies) I wouldn't object to making some meta-data mandatory, per Adam's comments. For example enforcing having an author and a license would be useful I think. Author gets us contact information and license is always worth clarifying. > - discoverability metadata is aggregated during the nightly quality > check processes and automatically commits that information to the > “bro/cban” repo. Would it be better to maintain this information outside of git in a state file that clients download? Otherwise the repository will clutter up quite a bit over time with tons of automatic commits. Overall, I agree that we can always add more restrictions later if it turns out necessary. It's not that we'll have 1000s of Bro modules in there within the first two weeks (as long as we prevent somebody spamming us). Robin -- Robin Sommer * ICSI/LBNL * [email protected] * www.icir.org/robin _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
