Re: Master build - failed due to Maven download fail

[Michael Miklavcic]

Thanks for jumping on that, Nick.

On Fri, May 24, 2019 at 10:40 AM Nick Allen  wrote:

> https://github.com/apache/metron/pull/1433
>
> On Fri, May 24, 2019 at 12:07 PM Nick Allen  wrote:
>
> > FYI, I just created this to track the issue.
> >
> > https://issues.apache.org/jira/browse/METRON-2143
> >
> > On Mon, May 20, 2019 at 6:39 PM Justin Leet 
> wrote:
> >
> >> I saw the same thing on https://github.com/apache/metron/pull/1407, but
> >> bouncing Travis fixed it. Not sure if it's a connection issue or what,
> but
> >> it seems like we should be able to cache it to avoid downloading every
> >> time.
> >>
> >> On Mon, May 20, 2019 at 6:14 PM Michael Miklavcic <
> >> michael.miklav...@gmail.com> wrote:
> >>
> >> > FYI I kicked off a rebuild for master. For some reason the wget
> command
> >> to
> >> > grab Maven 3.3.9 failed.
> >> >
> >>
> >
>

Re: Master build - failed due to Maven download fail

[Nick Allen]

https://github.com/apache/metron/pull/1433

On Fri, May 24, 2019 at 12:07 PM Nick Allen  wrote:

> FYI, I just created this to track the issue.
>
> https://issues.apache.org/jira/browse/METRON-2143
>
> On Mon, May 20, 2019 at 6:39 PM Justin Leet  wrote:
>
>> I saw the same thing on https://github.com/apache/metron/pull/1407, but
>> bouncing Travis fixed it. Not sure if it's a connection issue or what, but
>> it seems like we should be able to cache it to avoid downloading every
>> time.
>>
>> On Mon, May 20, 2019 at 6:14 PM Michael Miklavcic <
>> michael.miklav...@gmail.com> wrote:
>>
>> > FYI I kicked off a rebuild for master. For some reason the wget command
>> to
>> > grab Maven 3.3.9 failed.
>> >
>>
>

Re: Master build - failed due to Maven download fail

[Nick Allen]

FYI, I just created this to track the issue.

https://issues.apache.org/jira/browse/METRON-2143

On Mon, May 20, 2019 at 6:39 PM Justin Leet  wrote:

> I saw the same thing on https://github.com/apache/metron/pull/1407, but
> bouncing Travis fixed it. Not sure if it's a connection issue or what, but
> it seems like we should be able to cache it to avoid downloading every
> time.
>
> On Mon, May 20, 2019 at 6:14 PM Michael Miklavcic <
> michael.miklav...@gmail.com> wrote:
>
> > FYI I kicked off a rebuild for master. For some reason the wget command
> to
> > grab Maven 3.3.9 failed.
> >
>

Re: [DISCUSS] Parser Aggregation in Management UI

[Tibor Meller]

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 more about the process we followed with these PRs
please read the previous three message in this thread.

PR#1 METRON-2114: [UI] Moving components to sensor parser module

PR#2 METRON-2116: [UI] Removing redundant AppConfigService

PR#3 METRON-2117: [UI] Aligning models to grouping feature

PR#4 METRON-2115: [UI] Aligning UI to the parser aggregation AP

PR#5 METRON-2122: [UI] Fixing early app config access issue

PR#6 METRON-2124: [UI] Move status information and start/stop to the
Aggregate level 
PR#7 METRON-2125: [UI] Making changes visible in the parser list by marking
changed items 
PR#8 METRON-2131: Add NgRx and related dependencies

PR#9 METRON-2133: Add NgRx effects to communicate with the server

PR#10 METRON-2134: Add NgRx reducers to perform parser and group changes in
the store 
PR#11 METRON-2135: Add NgRx actions to trigger state changes

PR#12 METRON-2136: Add parser aggregation sidebar

PR#13 METRON-2137: Implement drag and drop mechanism and wire NgRx

PR#14 METRON-2138: Code clean up

PR#15 METRON-2139: Refactoring sensor-parser-config.component and wire NgRx


Thanks,
Tibor


On Thu, May 23, 2019 at 11:45 AM Tibor Meller 
wrote:

> 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 PR of the change request to the fixing commit to make them connected.
>
> On Wed, May 22, 2019 at 5:49 PM Michael Miklavcic <
> michael.miklav...@gmail.com> wrote:
>
>> 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 Meller 
>> wrote:
>>
>> > 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 states of the
>> code
>> > instead of the final one
>> > - none of those states of development are worth (or make sense) to be
>> > reviewed (initial phases of development are included in the original
>> commit
>> > history, multiple iterations of refactoring, etc.)
>> > - while the actual development history was irrelevant, the attribution
>> > aspect of it was still important
>> > *2. we divided** the changes by the original authors*
>> > - the original contributors were sardell, ruffle1986 and tiborm
>> > - we isolated the changes that belong to each individual contributor
>> > *3. each of us identified smaller but belonging changesets *
>> > - with this, we ended up opening 5 PRs from tiborm, 3 from sardell and 6
>> > from ruffle1986
>> > - each of these are smaller than 500 lines of changes, which makes the
>> task
>> > of reviewing easier
>> > - they have their own context and purpose described by the PR and the
>> > related Jira ticket
>> > *4. Each PR introduces a single new commit which is meant to be
>> reviewed*
>> > - with this we were able to open PRs on top of each others work, but the
>> > reviewer is still able to identify what changes were introduced and
>> > described by the pr simply by focusing on the last commit
>> > - the commit introduced by the PR has the same commit message as the
>> title
>> > of the PR to make it easier to find
>> > *5. Only the last PR is meant to be merged into the feature branch*
>> > - the last PR also introduces a single new commit to being reviewed
>> > - this contains all the commits from the previous PRs that belong to
>> parser
>> > aggregation
>> > - it builds fine in Travis
>> > - it's fully functional and ready to being tested against full dev
>> > -