The reason we decided to do that was because it is the best way for it to be used (and thus improved on and quality tested) by the broader bro community. If it's any indication of it's popularity, there was just an email on the bro mailing list about the plugin a few days ago, and I've already received a PR against my temporary holding place for this plugin to improve it (GitHub.com/jonzeolla/jzeolla-metron-bro-plugin-kafka), which would never have happened if it wasn't a standalone repo. Previously Nick pushed the code into a bro/plugins repo, which is now deprecated in favor of bro packages, but while it was there the community was able to identify issues which helped improve its quality.
By putting it in its own repo we were also able to turn it into a bro package, similar to debs or rpms but slightly different. This has numerous benefits, including turning setup into single command that installs and loads the plugin, in addition to handling version management and performing on installation unit tests to identify issues before use. I would advocate to treat this code as a dependancy, but not necessarily a core part of Metron, like we currently do. This also allows us to maintain separate versioning and release cycles (i.e. not necessarily lined up with Metron releases), which I expect will be very simple, infrequent, and easily tested. Happy to discuss this further - thanks, Jon On Mon, Nov 27, 2017, 17:58 James Sirota <jsir...@apache.org> wrote: > I agree with Nick. Since the plugin is tightly coupled with Metron why > not just pull it into the main repo and version it with the rest of the > code? Do we really need the second repo for the plug-in? > > Thanks, > James > > > > 16.11.2017, 08:06, "Nick Allen" <n...@nickallen.org>: > >> I would suggest that we institute a release procedure for the package > >> itself, but I don't think it necessarily has to line up with metron > >> releases (happy to be persuaded otherwise). Then we can just link > metron > >> to metron-bro-plugin-kafka by pointing to specific > >> metron-bro-plugin-kafka releases (git tags > >> < > http://bro-package-manager.readthedocs.io/en/stable/package.html#package- > >> versioning> > >> ). > >> Right now, full-dev spins up against the > >> apache/metron-bro-plugin-kafka master branch, which is not a good idea > to > >> have in place for an upcoming release. That is the crux of why I think > we > >> need to finalize the move to bro 2.5.2 and the plugin packaging before > our > >> next release (working on it as we speak). > >> Jon > > > > I replayed Jon's comments from the other thread above. > > > > My initial thought, is that I would not want to manage two separate > release > > processes. I don't want to have a roll call, cut release candidates and > > test both. > > > > I was thinking we would just need to change some of the behind-the-scenes > > processes handled by the release manager. This is one area where I had > > thought using a submodule in Git would help. > > > > On Thu, Nov 16, 2017 at 9:58 AM, Nick Allen <n...@nickallen.org> wrote: > > > >> + Restarting the thread to include mentors. > >> > >> The code of the 'Kafka Plugin for Bro' is now maintained in the > external > >> repository that we set up a while back. > >> > >> - Metron Core: git://git.apache.org/metron.git > >> - Kafka Plugin for Bro: git://git.apache.org/ > >> metron-bro-plugin-kafka.git > >> > >> (Q) Do we need to change anything in the release procedure to account > for > >> this? > > ------------------- > Thank you, > > James Sirota > PMC- Apache Metron > jsirota AT apache DOT org > -- Jon
