unsubscribe
-Original Message-
From: Tibor Meller [mailto:tibor.mel...@gmail.com]
Sent: Monday, July 1, 2019 11:07 AM
To: dev@metron.apache.org
Subject: Re: [DISCUSS] Parser Aggregation in Management UI
HI,
Can we continue the review process with the next PR in the line?
https
HI,
Can we continue the review process with the next PR in the line?
https://github.com/apache/metron/pull/1414
First three PR get merged to the feature branch by Ryan. Thanks for that!
On Tue, Jun 11, 2019 at 10:20 PM Michael Miklavcic <
michael.miklav...@gmail.com> wrote:
> Agreed Ryan, I know
Agreed Ryan, I know this is a bit of a cart before the horse scenario.
This isn't the most desirable of circumstances, and we're doing our best to
accommodate the contribution because it's a good feature to have, and the
work so far looks pretty solid. We have a bit more flexibility in a feature
b
I must have missed this comment - I think we should be merging the PRs into
the feature branch as they are completed and approved because we need the
review history associated with them. This also ensures that any changes
requested get appropriately resolved in the final version of the feature
bran
"We planning to add the changes to the latest PR as additional commits to
avoid impacting the PR sequence. We will refer to the source PR in the
commit message of the fix. Also adding a link to the comment section of the
source PR of the change request to the fixing commit to make them
connected."
Hi all,
*We still need some volunteer reviewers for this feature.* All individual
PR is under 1000 line of changes except one and it is due to an
autogenerated package.lock.json file.
Just a heads up: parser aggregation by default turned on for bro, snort and
yarn parser on full dev. Without this
Please find below the list of the PRs we opened for Parser Aggregation.
With Shane, Tamas we tried to provide as much information as possible to
make the reviewing process easier.
Please keep that in mind these PRs are not against muster but a Parser
Aggregation feature branch.
If you like to read
Yes, am expecting that some change request will rase due to the review.
We planning to add the changes to the latest PR as additional commits to
avoid impacting the PR sequence. We will refer to the source PR in the
commit message of the fix. Also adding a link to the comment section of the
source
Tibor, that sounds reasonable to me. If PR #1 ends up requiring code
changes, will you guys just percolate those up through the remaining k PRs
in order, or just the final PR? I'm wondering how this works in reference
to your last point in #5 about rebasing.
On Wed, May 22, 2019 at 8:47 AM Tibor M
I would like to describe quickly *our approach to breaking down Parser
Aggregation PR for smaller chunks*
*1. we squashed the commits in the original development branch*
- when we started to open smaller PRs from the commits from the original
branch, we found ourself opening PRs out of historical
You need to be a committer, that is all I think.
I would not use the github UI for it though, I do it through the cli
On May 8, 2019 at 09:45:24, Michael Miklavcic (michael.miklav...@gmail.com)
wrote:
Not that I'm aware of. Nick and Otto, you've created them before, did you
need any special per
Not that I'm aware of. Nick and Otto, you've created them before, did you
need any special perms?
On Wed, May 8, 2019 at 3:57 AM Shane Ardell
wrote:
> This morning, we started to break down our work as Michael suggested in
> this thread. However, it looks like I don't have permission to create a
This morning, we started to break down our work as Michael suggested in
this thread. However, it looks like I don't have permission to create a new
branch in the GitHub UI or push a new branch to the apache/metron repo. Is
this action restricted to PMC members only?
Shane
On Wed, May 8, 2019 at 9
Here's the process we've gone through in order to implement the feature.
At the beginning we had some bootstrap work like creating a mock API
(written in NodeJS) because we were a few steps ahead the backend part. But
this is in a totally different repository so it doesn't really count. We
also ha
This was my expectation as well.
Shane, Tibor, Tamas - how did you go about breaking this down into chunks
and/or microchunks when you collaborated offline? As Nick mentioned, you
obviously split up work and shared it amongst yourselves. Some explanation
around this process would be helpful for re
Ok, thanks for the clarification.
On Fri, May 3, 2019 at 5:49 AM Shane Ardell
wrote:
> NgRx was only used for the aggregation feature and doesn't go beyond that.
> I think the way I worded that sentence may have caused confusion. I just
> meant we use it to manage more pieces of state within the
Thanks Nick! That actually sounds promising.
Ryan are you ok with that if we open multiple smaller PR against the
Feature Branch you planning to create?
On Mon, May 6, 2019 at 4:19 PM Nick Allen wrote:
> Have you considered creating a feature branch for the effort? This would
> allow you to bre
Have you considered creating a feature branch for the effort? This would
allow you to break the effort into chunks, where the result of each PR may
not be a fully working "master-ready" result.
I am sure you guys tackled the work in chunks when developing it, so
consider just replaying those chunk
@Otto: I responded to your questions in a few Jira comment.
On Mon, May 6, 2019 at 11:21 AM Tibor Meller wrote:
> I wondered on the weekend how we could split that PR to smaller chunks.
> That PR is a result of almost 2 months of development and I don't see how
> to split that to multiple WORKIN
I wondered on the weekend how we could split that PR to smaller chunks.
That PR is a result of almost 2 months of development and I don't see how
to split that to multiple WORKING parts. It is as it is a whole working
feature. If we split it by packages or files we could provide smaller
non-functio
NgRx was only used for the aggregation feature and doesn't go beyond that.
I think the way I worded that sentence may have caused confusion. I just
meant we use it to manage more pieces of state within the aggregation
feature than just previous and current state of grouped parsers.
On Fri, May 3,
Shane, thanks for putting this together. The updates on the Jira are useful
as well.
> (we used it for more than just that in this feature, but that was the
initial reasoning)
What are you using NgRx for in the submitted work that goes beyond the
aggregation feature?
On Thu, May 2, 2019 at 12:2
I have commented the jira.
On May 2, 2019 at 14:22:41, Shane Ardell (shane.m.ard...@gmail.com) wrote:
Hello everyone,
In response to discussions in the 0.7.1 release thread, I wanted to start a
thread regarding the parser aggregation work for the Management UI. For
anyone who has not already
23 matches
Mail list logo