>> another incubator release? It depends on the timing. The last release took 3 weeks and 5 RCs to get approval as a release within the Metron community. Hopefully this one won’t be as hard, but it’s likely it will take a couple weeks, especially since this is my first cycle as Release Manager. If, as hoped, the Board graduates us to TLP at the Apr 19 meeting, this could become our first release as a TLP.
On the other hand, if it goes really fast, we could go ahead and submit it as another incubator release. And if graduation comes in the middle, we’d just withdraw that and re-vote as a TLP, on our own authority as delegated by the Board. Basically, either way works out. Thanks, --Matt From: Otto Fowler <ottobackwa...@gmail.com> Date: Tuesday, April 4, 2017 at 11:43 AM To: "dev@metron.incubator.apache.org" <dev@metron.incubator.apache.org>, Matt Foley <ma...@apache.org> Subject: Re: [DISCUSS] next release proposal So this would be another incubator release? On April 4, 2017 at 14:09:58, Matt Foley (ma...@apache.org) wrote: Hi all, Although it’s only been a few weeks since the last release was finally published, that process started in January :-) Also, the last commit in 0.3.1 was Feb 23, and there’s been a ton of really cool new stuff added since then: Biggest items: - Multiple commits for REST API (base Jira: METRON-503) - Multiple commits to work with Kerberized (secure) clusters (mult. Jiras) Other major new features: - METRON-690: DSL-based sparse time window specification for Profiler - METRON-733: Remove Geo db from ParserBolt - METRON-686: Record rule set that fired during Threat Triage - METRON-743: Sort files when reading results from Pcap - METRON-701: Triage metrics produced by Profiler - METRON-744: Stellar external functions loaded from HDFS (and huge speed-up for function resolution) - METRON-694: Index errors from Topologies, and - METRON-745: Create Error dashboards - METRON-712: Separate eval from parse in Stellar - METRON-765: Add GUID to messages - METRON-793: Updated to storm-kafka-client spout We’ve also had numerous bug fixes, docs improvements, and improvements to deployment tools (docker, ansible, mpack, quickdev, and fulldev). I think the REST API and Kerberization, by themselves, would justify a release. Along with the others, I’d like to propose that we make a release soon. The time frame I had in mind was at the end of this week I could cut a release branch (so on-going work in master doesn’t get blocked) and start the process of generating an RC. What do you-all think? Also, what additional work do you think should be included in this release, and can it realistically get done by the end of this week? The time frame is, of course, flexible at the pleasure of the community – but also, there will be another release in another couple months or so, so no need to rush stuff. Thanks, --Matt
