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
