> On May 23, 2016, at 4:59 PM, Robin Sommer <[email protected]> wrote: > >> That would make life easier for authors, and that’s maybe even a >> higher priority than maximizing the quality/consistency of user >> experience because, without authors, there won’t be much for users to >> experience in the first place. > > Yeah, that's exactly what I'm advocating: making it easy should really > be priority number one, with everything else coming second. If you see > ways to adapt the design to target that specifically, I'm all for it.
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: - still have a "bro/cban" github repository, but it now contains git submodules that point directly to other github accounts/repos - 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 — just check if the change is adding a submodule and then click a button to merge (don’t even have to look at the contents of the submodule). - a person that has submitted something to cban needs no further interaction with it and they resume their typical development workflow — cban client's “update” command will fetch/pull directly from their git repo. - all submodules get scanned by an out-of-band nightly process which checks for brokenness and other quality metrics - 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) - it’s not a big deal for a submodule to temporarily enter in to a broken state — cban users can always roll back to a previous version or just uninstall it. It’s up to the community to communicate/collaborate directly w/ the author here to get things fixed. - metadata associated w/ plugins is all optional, but its existence contributes to some arbitrary “quality” rating/metrics - 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) - discoverability metadata is aggregated during the nightly quality check processes and automatically commits that information to the “bro/cban” repo. Without doing this, I think cban clients would have an incredibly slow “search” command that goes out to each submodule individually and gathers metadata. (features related to discoverability might be lower priority in general) - interoperability metadata can also be aggregated nightly along the discoverability metadata, but when the cban client is actually going to perform specific operations on a particular submodule, it gets this data directly from the cloned submodule(s) to make sure the info is up-to-date. Version numbering can probably be done via git tags, but dependency info stored in a canonically named text file. I think all those points make things easy on contributors, minimize direct involvement of the Bro Team in sorting out problems related to particular plugins, and provide a useful way for users to discover and maintain Bro plugins. There’s more potential for users to encounter broken/bad plugins, but maybe that also encourages stronger community involvement w/ users more likely to try and help get problems resolved. - Jon _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
