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
