[Bro-Dev] CBAN design proposal
jan.grashoefer at gmail.com
Tue May 24 12:52:14 PDT 2016
> - 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.
I really like the community-centric approach. Regarding the discussion
about checks and consistency I think that basically all conventions,
that could be enforced automatically, will make the archive easier to
work with (for authors and for end-users). But there is another thing
that came to my mind: How are situations handled in which the author
becomes the bottleneck?
Imagine there was someone who published an awesome script but a new
version of Bro breaks it. Another one patched the script and sends the
patch to the original author. What will happen, in case he does not
respond? Personally I don't like repositories which end up with entries
like: "awesome-script", "awesome-script v2", "awesome-script by Jan" ...
To avoid this one might consider to support forking plugins or organize
the plugins user-centered ("jan/awesome-script", "anna/awesome-script").
More information about the bro-dev