[RESULT][VOTE] Metron Release Candidate 0.7.1-RC1

[Justin Leet <ju...@gmail.com>]

The vote has failed.  The voting was:

2 binding +1’s (Justin, Nick)
2 non-binding -1’s (Otto, Mike)
no 0’s

As discussed in the release thread, any further RC's are pending the review
and merge of PR#1360 <https://github.com/apache/metron/pull/1360> (Parser
aggregation UI implementation).

Thanks,
Justin

Re: [RESULT][VOTE] Metron Release Candidate 0.7.1-RC1

[Justin Leet <ju...@gmail.com>]

Mike is right, this is what I get for copy pasting, then not double
checking the email before I sent it.

I'd open up a discuss thread, rather than have it on the vote result thread.

On Tue, Apr 30, 2019 at 6:59 PM Michael Miklavcic <
michael.miklavcic@gmail.com> wrote:

> btw, it's 2 "binding" -1’s (Otto, Mike)
>
> I started taking a look at that PR and it looks like this isn't quite as
> close to being able go in as I had originally expected. I want to talk
> about options here. It seems to me that we can:
>
>    1. Wait for PR#1360 to go in, but this is likely going to take more time
>    than originally anticipated
>    2. Accept the issue in full dev, but add some notes in the developer
>    docs about the current feature gap and why sensors aren't showing
> status in
>    the management UI when aggregation is enabled.
>    3. Find some other workable UI solution.
>    4. Other option?
>
> All things considered, I'm personally leaning towards #2 in the short-term,
> but I think we should probably talk about this a bit before deciding what
> RC2 should be.
>
> Best,
> Mike
>
>
>
>
>
> On Tue, Apr 30, 2019 at 4:33 PM Justin Leet <ju...@gmail.com> wrote:
>
> > The vote has failed.  The voting was:
> >
> > 2 binding +1’s (Justin, Nick)
> > 2 non-binding -1’s (Otto, Mike)
> > no 0’s
> >
> > As discussed in the release thread, any further RC's are pending the
> review
> > and merge of PR#1360 <https://github.com/apache/metron/pull/1360>
> (Parser
> > aggregation UI implementation).
> >
> > Thanks,
> > Justin
> >
>

Re: [RESULT][VOTE] Metron Release Candidate 0.7.1-RC1

[Michael Miklavcic <mi...@gmail.com>]

btw, it's 2 "binding" -1’s (Otto, Mike)

I started taking a look at that PR and it looks like this isn't quite as
close to being able go in as I had originally expected. I want to talk
about options here. It seems to me that we can:

   1. Wait for PR#1360 to go in, but this is likely going to take more time
   than originally anticipated
   2. Accept the issue in full dev, but add some notes in the developer
   docs about the current feature gap and why sensors aren't showing status in
   the management UI when aggregation is enabled.
   3. Find some other workable UI solution.
   4. Other option?

All things considered, I'm personally leaning towards #2 in the short-term,
but I think we should probably talk about this a bit before deciding what
RC2 should be.

Best,
Mike





On Tue, Apr 30, 2019 at 4:33 PM Justin Leet <ju...@gmail.com> wrote:

> The vote has failed.  The voting was:
>
> 2 binding +1’s (Justin, Nick)
> 2 non-binding -1’s (Otto, Mike)
> no 0’s
>
> As discussed in the release thread, any further RC's are pending the review
> and merge of PR#1360 <https://github.com/apache/metron/pull/1360> (Parser
> aggregation UI implementation).
>
> Thanks,
> Justin
>