Thanks, we’re now up to 4 backward-incompatible issues. Any others should be so marked?
On 4/17/17, 4:43 PM, "Matt Foley" <ma...@apache.org> wrote: Hi all, Out of the 58 Jiras resolved, completely or partially, between 0.3.1 and 0.4.0, only one is labeled “backward-incompatible” and has text in the “Docs Text” field. And it’s super minor (METRON-771). Is this really true? If so, great, but if not, please help people upgrade without glitches: Fix these fields in your jiras, so they can be included in the Release Notes. a) In the “Labels” field, add “backward-incompatible”. (It will autocomplete for you.) b) In the “Doc Text” field, say what the issue is and what a person upgrading should do about it, if anything. As usual, non-response will be considered positive confirmation that no response is necessary :-) Please try to address in the next day or so. Thanks, Your humble Release Manager On 4/12/17, 10:59 AM, "zeo...@gmail.com" <zeo...@gmail.com> wrote: I agree conceptually but haven't looked at them each individually to see how much they impact and if a short timeline for merging is reasonable. METRON-821 just needs a minor change and then a final run-through before I'm comfortable merging it in. Jon On Wed, Apr 12, 2017 at 11:44 AM Nick Allen <n...@nickallen.org> wrote: > It would be nice to close out all the "Kerberos" related PRs prior to the > release. Let me know if anyone thinks any of these are not feasible for > the release. > > To that end I went through and reviewed some of the outstanding ones below > to try and help move them along. Any others willing to help would be much > appreciated. > > METRON-836 Use Pycapa with Kerberos > #524 opened 18 hours ago by nickwallen > > METRON-835 Use Profiler with Kerberos > #521 opened 2 days ago by nickwalle > > METRON-833: Update MaaS documentation to explain how it interacts with > kerberos > #520 opened 5 days ago by cestella > > METRON-799: The MPack should function in a kerberized cluster > #518 opened 5 days ago by justinlee > > METRON-821 Minor fixes in full dev kerberos setup instructions > #510 opened 8 days ago by JonZeolla 4 of 4 > > METRON-819: Document kafka console producer parameter for sensors with > kerberos > #507 opened 9 days ago by mmiklavc 4 of 4 > > > > > > On Tue, Apr 4, 2017 at 2:09 PM, 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 > > > > > > > -- Jon