date:20170705

Github user jjmeyer0 commented on the issue:

https://github.com/apache/metron/pull/633
  
Quote from @justinleet 
> I'd be inclined towards avoiding splitting the build if we were only 
getting a couple minutes out of it. I'm a little worried about being able to 
get three slots on the occasionally stretched Apache setup. Integration tests 
and building are the long poles in the tent, so splitting out the other tests 
doesn't really save us much time here, unfortunately.

I agree, I have reverted this.



Quote from @ottobackwards 
> I'm going to be honest. Now that we have the builds kind of working 
again, I'm a little hesitant to change them for anything but an absolute 
certainty of a return, that we completely understand.
> 
> I think the travis build strategy should be a longer living branch maybe.

I reverted the multiple env changes, as I agree, it's not worth the small 
chunk of time that was shaved off. However, I think the rest of these changes 
can be helpful for the following reasons:

* moving the license verification to an earlier step can help the build 
fail fast. Forgetting to update the dependency file can be a common mistake. 
Failing earlier might save time and travis resources.
* I believe moving to trusty was recommended by travis-ci
* using travis' install step for the `mvn install`. No benefit that I know 
of. I just believe `mvn install` should happen here.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron pull request #633: METRON-1008: Updating travis to use trusty, moved ...

GitHub user jjmeyer0 opened a pull request:

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

METRON-1008: Updating travis to use trusty, moved install to install â¦

â¦step, moved verify license to earlier step, and added .npm to cache.

## Contributor Comments
This is a continuation of 
[PR-632](https://github.com/apache/metron/pull/632) due to github not allowing 
a PR to be re-opened when a force push occurred.  


## Pull Request Checklist

Thank you for submitting a contribution to Apache Metron.  
Please refer to our [Development 
Guidelines](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61332235)
 for the complete guide to follow for contributions.  
Please refer also to our [Build Verification 
Guidelines](https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds?show-miniview)
 for complete smoke testing guides.  


In order to streamline the review of the contribution we ask you follow 
these guidelines and ask you to double check the following:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? If not one needs to 
be created at [Metron 
Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel).
 
- [ ] Does your PR title start with METRON- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.
- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?


### For code changes:
- [ ] Have you included steps to reproduce the behavior or problem that is 
being changed or addressed?
- [ ] Have you included steps or a guide to how the change may be verified 
and tested manually?
- [ ] Have you ensured that the full suite of tests and checks have been 
executed in the root incubating-metron folder via:
  ```
  mvn -q clean integration-test install && build_utils/verify_licenses.sh 
  ```

- [ ] Have you written or updated unit tests and or integration tests to 
verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] Have you verified the basic functionality of the build by building 
and running locally with Vagrant full-dev environment or the equivalent?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered by building and verifying the site-book? If not then run 
the following commands and the verify changes via 
`site-book/target/site/index.html`:

  ```
  cd site-book
  mvn site
  ```

 Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.
It is also recommended that [travis-ci](https://travis-ci.org) is set up 
for your personal repository such that your branches are built there before 
submitting a pull request.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jjmeyer0/incubator-metron METRON-1008

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/metron/pull/633.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #633


commit eb3abe1ae2eb5ff89a7e2bcb183d0bdf54f021b8
Author: JJ 
Date:   2017-06-29T22:43:58Z

METRON-1008: Updating travis to use trusty, moved install to install step, 
moved verify license to earlier step, and added .npm to cache.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #632: METRON-1008: Updating travis to use trusty

Github user jjmeyer0 commented on the issue:

https://github.com/apache/metron/pull/632
  
Unfortunately I will have to open a new PR. I squashed my commits when this 
PR was closed. Github doesn't allow to reopen PRs when force pushes occur when 
the PR is closed.  @justinleet and @ottobackwards I'll address your comments on 
the new PR.

My apologies, I was not aware of this. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[VOTE][PROPOSAL] minor changes to release process

(The below proposal is also stated in 
https://issues.apache.org/jira/browse/METRON-1020 )

The following proposed changes are small, but not just editorial in nature, 
hence will require vote of the community to change. Our bylaws don’t have an 
action type of Modifying Policy, but it’s probably fair to consider policies to 
be “included by reference” in Bylaws, so let’s vote on this like a Bylaws 
change.  “Lazy majority of PMC members” applies – same as a release.

Regarding the process at 
https://cwiki.apache.org/confluence/display/METRON/Release+Process :

1. Add a step to tag the final release, as 
"apache-metron--release".

2. The current policy says that when a critical release is urgently needed, 
"the 72 hour waiting periods in Steps 7 and 8 can be waived." The formerly 
referenced Step 8 was for the Incubator vote, so that can be removed as an 
editorial issue, but we should also allow for not waiting for mirror 
propagation – let the mirrors catch up as fast as they can. So the text should 
now read: "the 72 hour waiting period in Step 7 and the wait for mirror 
propagation in Step 10 can be waived."

3. Finally, it is good practice to increment the build version in POMs 
immediately AFTER a release, so that builds with new stuff cannot be mistaken 
for builds of the release version. The current policy says to increment it just 
BEFORE a release. I suggest changing this to say:
a) immediately after a release, increment the MINOR version number (eg, with 
the 0.4.0 just released, set the new version number to 0.4.1)
b) immediately before a release, decide whether it will be a minor or major 
release. If minor, assure that the minor version number was already incremented 
after the last release and continue to use that number. If major, change the 
version number to the desired new major version. 
c) These version number changes are in master branch.  Creation of new branches 
does not occur until the idea of creating a maintenance branch or a new release 
branch has been consented by the community.

Please share your thoughts and/or vote.
Thanks,
--Matt

Re: [ANNOUNCE] Apache Metron 0.4.0 release

2017-07-05 Thread Justin Leet

Congrats, everyone!  A lot of people helped out across the board, and I
look forward to everyone's contributions moving ahead.

On Wed, Jul 5, 2017 at 4:47 PM, Otto Fowler  wrote:

> Thank you Matt, your first metron release as well!
> Congratulations to the community.
>
>
> On July 5, 2017 at 16:35:47, Matt Foley (ma...@apache.org) wrote:
>
> Friends and Colleagues,
> I’m happy to announce the completion and release of Apache Metron 0.4.0.
> Besides a bunch of great new features, this is also our first release as a
> TLP.
>
> The public website at http://metron.apache.org/ has been updated and has
> correct links to the new downloads and docs.
>
> Full list of changes in this release is in the Release Notes:
> http://www.apache.org/dyn/closer.cgi/metron/0.4.0/RELEASE_NOTES
>
> And the release point is tagged in github as
> “apache-metron-0.4.0-release”, viewable at:
> https://github.com/apache/metron/tree/apache-metron-0.4.0-release
> This is also the same has HEAD of Metron_0.4.0 branch.
>
> Every release is a team effort, and this one with 140+ tasks and bug
> fixes, certainly involved the whole community. Congratulations and THANK
> YOU to everyone who contributed, whether ideas, code, reviews,
> documentation, or testing.
>
> Best regards,
> --Matt (as Release Manager)
>
>
>
>

Re: [ANNOUNCE] Apache Metron 0.4.0 release

2017-07-05 Thread Otto Fowler

Thank you Matt, your first metron release as well!
Congratulations to the community.


On July 5, 2017 at 16:35:47, Matt Foley (ma...@apache.org) wrote:

Friends and Colleagues,
I’m happy to announce the completion and release of Apache Metron 0.4.0.
Besides a bunch of great new features, this is also our first release as a
TLP.

The public website at http://metron.apache.org/ has been updated and has
correct links to the new downloads and docs.

Full list of changes in this release is in the Release Notes:
http://www.apache.org/dyn/closer.cgi/metron/0.4.0/RELEASE_NOTES

And the release point is tagged in github as “apache-metron-0.4.0-release”,
viewable at:
https://github.com/apache/metron/tree/apache-metron-0.4.0-release
This is also the same has HEAD of Metron_0.4.0 branch.

Every release is a team effort, and this one with 140+ tasks and bug fixes,
certainly involved the whole community. Congratulations and THANK YOU to
everyone who contributed, whether ideas, code, reviews, documentation, or
testing.

Best regards,
--Matt (as Release Manager)

Re: [ANNOUNCE] Apache Metron 0.4.0 release

BTW, if you’ve recently accessed any URIs under http://metron.apache.org/, you 
may need to hit “refresh” in your browser to see the new updated versions.

On 7/5/17, 1:35 PM, "Matt Foley"  wrote:

Friends and Colleagues,
I’m happy to announce the completion and release of Apache Metron 0.4.0.
Besides a bunch of great new features, this is also our first release as a 
TLP.

The public website at http://metron.apache.org/ has been updated and has 
correct links to the new downloads and docs.

Full list of changes in this release is in the Release Notes:
http://www.apache.org/dyn/closer.cgi/metron/0.4.0/RELEASE_NOTES 

And the release point is tagged in github as “apache-metron-0.4.0-release”, 
viewable at:
https://github.com/apache/metron/tree/apache-metron-0.4.0-release
This is also the same has HEAD of Metron_0.4.0 branch.

Every release is a team effort, and this one with 140+ tasks and bug fixes, 
certainly involved the whole community. Congratulations and THANK YOU to 
everyone who contributed, whether ideas, code, reviews, documentation, or 
testing.

Best regards,
--Matt (as Release Manager)

[GitHub] metron issue #632: METRON-1008: Updating travis to use trusty

Github user JonZeolla commented on the issue:

https://github.com/apache/metron/pull/632
  
Obviously I was not very clear about what I was commenting on either so 
sorry about that.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[ANNOUNCE] Apache Metron 0.4.0 release

Friends and Colleagues,
I’m happy to announce the completion and release of Apache Metron 0.4.0.
Besides a bunch of great new features, this is also our first release as a TLP.

The public website at http://metron.apache.org/ has been updated and has 
correct links to the new downloads and docs.

Full list of changes in this release is in the Release Notes:
http://www.apache.org/dyn/closer.cgi/metron/0.4.0/RELEASE_NOTES 

And the release point is tagged in github as “apache-metron-0.4.0-release”, 
viewable at:
https://github.com/apache/metron/tree/apache-metron-0.4.0-release
This is also the same has HEAD of Metron_0.4.0 branch.

Every release is a team effort, and this one with 140+ tasks and bug fixes, 
certainly involved the whole community. Congratulations and THANK YOU to 
everyone who contributed, whether ideas, code, reviews, documentation, or 
testing.

Best regards,
--Matt (as Release Manager)

[GitHub] metron issue #632: METRON-1008: Updating travis to use trusty

Github user justinleet commented on the issue:

https://github.com/apache/metron/pull/632
  
@JonZeolla ahh, I thought you were just making a note, so everyone knew 
that recommendation.  Sorry about that.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #632: METRON-1008: Updating travis to use trusty

2017-07-05 Thread ottobackwards

Github user ottobackwards commented on the issue:

https://github.com/apache/metron/pull/632
  
I'm going to be honest.  Now that we have the builds kind of working again, 
I'm a little hesitant to change them for anything but an absolute certainty of 
a return, that we completely understand.

I think the travis build strategy should be a longer living branch maybe.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #632: METRON-1008: Updating travis to use trusty

Github user jjmeyer0 commented on the issue:

https://github.com/apache/metron/pull/632
  
@JonZeolla that was a squashed commit that was probably a typo. I'll remove 
it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #632: METRON-1008: Updating travis to use trusty

Github user JonZeolla commented on the issue:

https://github.com/apache/metron/pull/632
  
I was addressing "Testing sudo as false." In the body of the message above.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #632: METRON-1008: Updating travis to use trusty

Github user justinleet commented on the issue:

https://github.com/apache/metron/pull/632
  
I'd be inclined towards avoiding splitting the build if we were only 
getting a couple minutes out of it.  I'm a little worried about being able to 
get three slots on the occasionally stretched Apache setup.  Integration tests 
and building are the long poles in the tent, so splitting out the other tests 
doesn't really save us much time here, unfortunately.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #632: METRON-1008: Updating travis to use trusty

Github user justinleet commented on the issue:

https://github.com/apache/metron/pull/632
  
@JonZeolla Completely counterintuitively, `sudo: required` is the 
counterpart of `sudo: false`.  So this already got taken care of as part of 
METRON-1004.  See: https://docs.travis-ci.com/user/trusty-ci-environment.

If you check out the Travis build 
(https://travis-ci.org/apache/metron/jobs/250503026, for example), it says it's 
running the Trusty as expected.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron pull request #632: METRON-1008: Updating travis to use trusty

GitHub user jjmeyer0 reopened a pull request:

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

METRON-1008: Updating travis to use trusty

â¦.npm to cache.

Added some more cacheing from 1004 ticket.

Revert some changes.

Reverted environment and put maven opts in the correct spot.

Testing sudo as false.

Trying multiple vm build.

Revert back to two threads on maven install.

## Contributor Comments
I made travis use trusty. On top of this the following were added before 
1004 was made, but I thought some things were worth keeping:

* Call to verify license is made right away to get quicker failures. 
* Cache $HOME/.npm; After bringing in METRON-1004 it looks like this may 
not be needed anymore?
* Set MAVEN_OPTS to set `-Xmx2g` out of curiosity
* Out of curiosity, multiple environments were added to see if build times 
would dramatically increase. I know this may be undesirable, but I thought I'd 
leave it in to discuss some. I'm leaning towards reverting this back as it only 
seems to get it down to ~23 minutes. Any thoughts?


## Pull Request Checklist

Thank you for submitting a contribution to Apache Metron.  
Please refer to our [Development 
Guidelines](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61332235)
 for the complete guide to follow for contributions.  
Please refer also to our [Build Verification 
Guidelines](https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds?show-miniview)
 for complete smoke testing guides.  


In order to streamline the review of the contribution we ask you follow 
these guidelines and ask you to double check the following:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? If not one needs to 
be created at [Metron 
Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel).
 
- [ ] Does your PR title start with METRON- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.
- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?


### For code changes:
- [ ] Have you included steps to reproduce the behavior or problem that is 
being changed or addressed?
- [ ] Have you included steps or a guide to how the change may be verified 
and tested manually?
- [ ] Have you ensured that the full suite of tests and checks have been 
executed in the root incubating-metron folder via:
  ```
  mvn -q clean integration-test install && build_utils/verify_licenses.sh 
  ```

- [ ] Have you written or updated unit tests and or integration tests to 
verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] Have you verified the basic functionality of the build by building 
and running locally with Vagrant full-dev environment or the equivalent?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered by building and verifying the site-book? If not then run 
the following commands and the verify changes via 
`site-book/target/site/index.html`:

  ```
  cd site-book
  mvn site
  ```

 Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.
It is also recommended that [travis-ci](https://travis-ci.org) is set up 
for your personal repository such that your branches are built there before 
submitting a pull request.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jjmeyer0/incubator-metron METRON-1008

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/metron/pull/632.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #632


commit cc9f234fd51493684767c854fc52d0fba7856496
Author: JJ 
Date:   2017-06-29T22:43:58Z

METRON-1008: Updating travis to use trusty, increase heap, and added .npm 
to cache.

Added some more cacheing from 1004 ticket.

Revert some changes.

Reverted environment and put maven opts in the correct spot.

Testing sudo as false.

Trying multiple vm build.

Revert back to two threads on maven install.

commit a2a07df29f048cbf35c5f85d83073c2d776d93d8
Author: JJ 
Date:   2017-07-05T18:51:17Z

Properly setting MAVEN_OPTS.

commit 6587c0a3c469267b6fb20864b4ea16068b127e68
Author: JJ

[GitHub] metron issue #572: METRON-633: Create better logging for HbaseEnrichmentWrit...

2017-07-05 Thread zezutom

Github user zezutom commented on the issue:

https://github.com/apache/metron/pull/572
  
@justinleet Will do, thanks for sorting out Travis!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron pull request #632: METRON-1008: Updating travis to use trusty

Github user jjmeyer0 closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #632: METRON-1008: Updating travis to use trusty

Github user JonZeolla commented on the issue:

https://github.com/apache/metron/pull/632
  
One brief note - I spoke to a friend on the travis infrastructure team and 
she recommended that if our build takes > 5m we should run on the VM (sudo: 
true).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron pull request #632: METRON-1008: Updating travis to use trusty

GitHub user jjmeyer0 opened a pull request:

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

METRON-1008: Updating travis to use trusty

â¦.npm to cache.

Added some more cacheing from 1004 ticket.

Revert some changes.

Reverted environment and put maven opts in the correct spot.

Testing sudo as false.

Trying multiple vm build.

Revert back to two threads on maven install.

## Contributor Comments
I made travis use trusty. On top of this the following were added before 
1004 was made, but I thought some things were worth keeping:

* Call to verify license is made right away to get quicker failures. 
* Cache $HOME/.npm; After bringing in METRON-1004 it looks like this may 
not be needed anymore?
* Set MAVEN_OPTS to set `-Xmx2g` out of curiosity
* Out of curiosity, multiple environments were added to see if build times 
would dramatically increase. I know this may be undesirable, but I thought I'd 
leave it in to discuss some. I'm leaning towards reverting this back as it only 
seems to get it down to ~23 minutes. Any thoughts?


## Pull Request Checklist

Thank you for submitting a contribution to Apache Metron.  
Please refer to our [Development 
Guidelines](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61332235)
 for the complete guide to follow for contributions.  
Please refer also to our [Build Verification 
Guidelines](https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds?show-miniview)
 for complete smoke testing guides.  


In order to streamline the review of the contribution we ask you follow 
these guidelines and ask you to double check the following:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? If not one needs to 
be created at [Metron 
Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel).
 
- [ ] Does your PR title start with METRON- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.
- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?


### For code changes:
- [ ] Have you included steps to reproduce the behavior or problem that is 
being changed or addressed?
- [ ] Have you included steps or a guide to how the change may be verified 
and tested manually?
- [ ] Have you ensured that the full suite of tests and checks have been 
executed in the root incubating-metron folder via:
  ```
  mvn -q clean integration-test install && build_utils/verify_licenses.sh 
  ```

- [ ] Have you written or updated unit tests and or integration tests to 
verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] Have you verified the basic functionality of the build by building 
and running locally with Vagrant full-dev environment or the equivalent?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered by building and verifying the site-book? If not then run 
the following commands and the verify changes via 
`site-book/target/site/index.html`:

  ```
  cd site-book
  mvn site
  ```

 Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.
It is also recommended that [travis-ci](https://travis-ci.org) is set up 
for your personal repository such that your branches are built there before 
submitting a pull request.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jjmeyer0/incubator-metron METRON-1008

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/metron/pull/632.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #632


commit cc9f234fd51493684767c854fc52d0fba7856496
Author: JJ 
Date:   2017-06-29T22:43:58Z

METRON-1008: Updating travis to use trusty, increase heap, and added .npm 
to cache.

Added some more cacheing from 1004 ticket.

Revert some changes.

Reverted environment and put maven opts in the correct spot.

Testing sudo as false.

Trying multiple vm build.

Revert back to two threads on maven install.

commit a2a07df29f048cbf35c5f85d83073c2d776d93d8
Author: JJ 
Date:   2017-07-05T18:51:17Z

Properly setting MAVEN_OPTS.




---
If your project is set up for it, you can reply

[GitHub] metron pull request #631: METRON-1019: Metron 0.4.0 manual installation guid...

2017-07-05 Thread lvets

GitHub user lvets opened a pull request:

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

METRON-1019: Metron 0.4.0 manual installation guide for CentOS 6

## Contributor Comments
This is a PR to METRON-1019.
Is adds a manual installation guide for Metron 0.4.0 on CentOS 6 under a 
new directory 'other-examples'. Additionally, it explains how to install MySQL 
for the REST UI as well as Apache NiFi for log ingestion.
No code changes are included, this is purely documentation.

## Pull Request Checklist

Thank you for submitting a contribution to Apache Metron.  
Please refer to our [Development 
Guidelines](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61332235)
 for the complete guide to follow for contributions.  
Please refer also to our [Build Verification 
Guidelines](https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds?show-miniview)
 for complete smoke testing guides.  


In order to streamline the review of the contribution we ask you follow 
these guidelines and ask you to double check the following:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? If not one needs to 
be created at [Metron 
Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel).
 
- [x] Does your PR title start with METRON- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.
- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?


### For code changes:
- [ ] Have you included steps to reproduce the behavior or problem that is 
being changed or addressed?
- [ ] Have you included steps or a guide to how the change may be verified 
and tested manually?
- [ ] Have you ensured that the full suite of tests and checks have been 
executed in the root incubating-metron folder via:
  ```
  mvn -q clean integration-test install && build_utils/verify_licenses.sh 
  ```

- [ ] Have you written or updated unit tests and or integration tests to 
verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] Have you verified the basic functionality of the build by building 
and running locally with Vagrant full-dev environment or the equivalent?

### For documentation related changes:
- [x] Have you ensured that format looks appropriate for the output in 
which it is rendered by building and verifying the site-book? If not then run 
the following commands and the verify changes via 
`site-book/target/site/index.html`:

  ```
  cd site-book
  mvn site
  ```

 Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.
It is also recommended that [travis-ci](https://travis-ci.org) is set up 
for your personal repository such that your branches are built there before 
submitting a pull request.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/lvets/metron METRON-1019

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/metron/pull/631.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #631


commit a3b381957fcd238fbdea3e88e3f9c7258a65d9d2
Author: Laurens Vets 
Date:   2017-07-05T17:36:06Z

Add manual install guide for Metron 0.4.0 on Centos 6

commit 170eeb507560683b2d523d7e13ebb9452b7f5868
Author: Laurens Vets 
Date:   2017-07-05T18:15:26Z

Add and clean up manual install guide for Metron 0.4.0 on Centos 6




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron pull request #629: METRON-1012 Update Metron public web site for 0.4....

2017-07-05 Thread asfgit

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [Request for Consensus Approval] dev branch for Stellar additional work

And another way suggested by Jon’s statement, is to not squash the commit, but 
leave at least one of each committer’s contributions intact.  That might not be 
too hard to add to the prepare-commit script, it’s just an invocation of 
interactive rebase/squash.

On 7/5/17, 10:32 AM, "Matt Foley"  wrote:

Jon, good point.  I was thinking we would just use the commit message to 
share attribution.  

It would be nicer to do something that would be picked up by github’s 
commit attribution, but unfortunately there is only one “author” field in a git 
commit metadata.  There are discussions online about allowing multiple 
instances of that field, and the maintainers don’t seem willing to do so 
currently.  There seems to be considerable support in the community for putting 
a LIST of authors in that single field; see:

https://stackoverflow.com/questions/7442112/attributing-a-single-commit-to-multiple-developers
and perhaps even this tool:
https://github.com/chrisk/git-pair
but it isn’t clear that github can correctly extract the email addresses in 
that case.  Github uses the metadata emails to attribute authorship, see

https://help.github.com/articles/updating-commit-author-attribution-with-github-importer/

I’d be willing to experiment a little to see if github can pick up multiple 
emails, but I wouldn’t bet on it.

Another way to do it would be with trivial commits following the real 
commit, one per additional author besides the committer.  This method would 
count commits correctly, but not LOC.
--Matt

On 7/5/17, 6:22 AM, "zeo...@gmail.com"  wrote:

That all sounds pretty reasonable to me.  My biggest concern would be
attribution during step 5 - we would need to make sure it isn't squash
merged like we typically do (assuming we do properly squash merge into
the speculative
branch).  Not a big issue though, I guess, just need to make sure it 
isn't
overlooked.

Jon

On Wed, Jul 5, 2017 at 4:40 AM Matt Foley  wrote:

> Now that METRON-877 is in, I would like to proceed with Steps 3-6 of 
the
> remaining work to separate out Stellar functionality as an independent
> module.  A couple people have suggested that this further development
> should be done in a Metron “dev branch”, where:
> a) changes are more visible than in a single person’s private 
development
> branch, and
> b) work can proceed for several days or a couple weeks on a branch 
that
> the collaborators may choose to keep stable for the duration (ie, 
without
> constantly updating to master).
>
> This concept was discussed as a “speculative branch” in this email 
thread:
> 
https://lists.apache.org/thread.html/391e15347ad625c4aa61e81f5dd238c0acb4048b8d77f93313298263@%3Cdev.metron.apache.org%3E
> but I don’t see that we ever actually changed our bylaws to mention 
it.
>
> Nevertheless, it falls within the purview of the PMC to create new
> branches in our code tree, and I request PMC members to give me a lazy
> consensus vote to do so.  Please +1 this email if you agree.
>
> The proposed rules of engagement are (drawn from issues raised in that
> email thread):
> 1. Commits to this branch to have the same rules as to master:  Jira, 
PR,
> and at least one +1 from a knowledgeable reviewer, and no -1’s.
> 2. +1 reviews may come from any participating contributor, not only
> current committers.  But commits still have to be made by a 
committer, so
> we don’t have to create new auth infra for this branch.
> 3. The branch should be updated from master at least every second 
week, or
> more frequently.  This may be adjusted to avoid disruption of work in
> progress.
> 4. PR’s to master will be posted for review as soon as self-consistent
> chunks of useful functionality are done.  The collaborators will 
define
> those chunks, but a rough goal is every two weeks.  The goal is to 
avoid
> mega-patches to review.
> 5. PR’s to master will be posted by a single developer from their home
> github repo, not directly from the speculative branch, so that
> collaborative work can proceed on the speculative branch.
> 6. The PR’s will be credited equally to all collaborators active 
during
> that “chunk” of work.
> 7. PR’s to master have to be reviewed and agreed to as though they 
were
> new patches. (The fact they were previously accepted into the 
speculative
> branch is at most a recommendation, not an a priori decision to let 
them
> into master.) The usual rules apply.  While collaborators will likely 
want
> to

Re: [Request for Consensus Approval] dev branch for Stellar additional work

2017-07-05 Thread Otto Fowler

Yeah, this is part of why we need the guide


On July 5, 2017 at 09:23:03, zeo...@gmail.com (zeo...@gmail.com) wrote:

That all sounds pretty reasonable to me. My biggest concern would be
attribution during step 5 - we would need to make sure it isn't squash
merged like we typically do (assuming we do properly squash merge into
the speculative
branch). Not a big issue though, I guess, just need to make sure it isn't
overlooked.

Jon

On Wed, Jul 5, 2017 at 4:40 AM Matt Foley  wrote:

> Now that METRON-877 is in, I would like to proceed with Steps 3-6 of the
> remaining work to separate out Stellar functionality as an independent
> module. A couple people have suggested that this further development
> should be done in a Metron “dev branch”, where:
> a) changes are more visible than in a single person’s private development
> branch, and
> b) work can proceed for several days or a couple weeks on a branch that
> the collaborators may choose to keep stable for the duration (ie, without
> constantly updating to master).
>
> This concept was discussed as a “speculative branch” in this email
thread:
>
https://lists.apache.org/thread.html/391e15347ad625c4aa61e81f5dd238c0acb4048b8d77f93313298263@%3Cdev.metron.apache.org%3E
> but I don’t see that we ever actually changed our bylaws to mention it.
>
> Nevertheless, it falls within the purview of the PMC to create new
> branches in our code tree, and I request PMC members to give me a lazy
> consensus vote to do so. Please +1 this email if you agree.
>
> The proposed rules of engagement are (drawn from issues raised in that
> email thread):
> 1. Commits to this branch to have the same rules as to master: Jira, PR,
> and at least one +1 from a knowledgeable reviewer, and no -1’s.
> 2. +1 reviews may come from any participating contributor, not only
> current committers. But commits still have to be made by a committer, so
> we don’t have to create new auth infra for this branch.
> 3. The branch should be updated from master at least every second week,
or
> more frequently. This may be adjusted to avoid disruption of work in
> progress.
> 4. PR’s to master will be posted for review as soon as self-consistent
> chunks of useful functionality are done. The collaborators will define
> those chunks, but a rough goal is every two weeks. The goal is to avoid
> mega-patches to review.
> 5. PR’s to master will be posted by a single developer from their home
> github repo, not directly from the speculative branch, so that
> collaborative work can proceed on the speculative branch.
> 6. The PR’s will be credited equally to all collaborators active during
> that “chunk” of work.
> 7. PR’s to master have to be reviewed and agreed to as though they were
> new patches. (The fact they were previously accepted into the speculative
> branch is at most a recommendation, not an a priori decision to let them
> into master.) The usual rules apply. While collaborators will likely want
> to +1 such PRs, sufficient time must be provided for other community
> members to review and raise issues.
>
> Thanks,
> --Matt
>
>
>
> --

Jon

[GitHub] metron issue #629: METRON-1012 Update Metron public web site for 0.4.0 relea...

Github user mattf-horton commented on the issue:

https://github.com/apache/metron/pull/629
  
Thanks, I'll proceed on @justinleet and @ottobackwards 's +1s.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [Request for Consensus Approval] dev branch for Stellar additional work

Jon, good point.  I was thinking we would just use the commit message to share 
attribution.  

It would be nicer to do something that would be picked up by github’s commit 
attribution, but unfortunately there is only one “author” field in a git commit 
metadata.  There are discussions online about allowing multiple instances of 
that field, and the maintainers don’t seem willing to do so currently.  There 
seems to be considerable support in the community for putting a LIST of authors 
in that single field; see:
https://stackoverflow.com/questions/7442112/attributing-a-single-commit-to-multiple-developers
and perhaps even this tool:
https://github.com/chrisk/git-pair
but it isn’t clear that github can correctly extract the email addresses in 
that case.  Github uses the metadata emails to attribute authorship, see
https://help.github.com/articles/updating-commit-author-attribution-with-github-importer/

I’d be willing to experiment a little to see if github can pick up multiple 
emails, but I wouldn’t bet on it.

Another way to do it would be with trivial commits following the real commit, 
one per additional author besides the committer.  This method would count 
commits correctly, but not LOC.
--Matt

On 7/5/17, 6:22 AM, "zeo...@gmail.com"  wrote:

That all sounds pretty reasonable to me.  My biggest concern would be
attribution during step 5 - we would need to make sure it isn't squash
merged like we typically do (assuming we do properly squash merge into
the speculative
branch).  Not a big issue though, I guess, just need to make sure it isn't
overlooked.

Jon

On Wed, Jul 5, 2017 at 4:40 AM Matt Foley  wrote:

> Now that METRON-877 is in, I would like to proceed with Steps 3-6 of the
> remaining work to separate out Stellar functionality as an independent
> module.  A couple people have suggested that this further development
> should be done in a Metron “dev branch”, where:
> a) changes are more visible than in a single person’s private development
> branch, and
> b) work can proceed for several days or a couple weeks on a branch that
> the collaborators may choose to keep stable for the duration (ie, without
> constantly updating to master).
>
> This concept was discussed as a “speculative branch” in this email thread:
> 
https://lists.apache.org/thread.html/391e15347ad625c4aa61e81f5dd238c0acb4048b8d77f93313298263@%3Cdev.metron.apache.org%3E
> but I don’t see that we ever actually changed our bylaws to mention it.
>
> Nevertheless, it falls within the purview of the PMC to create new
> branches in our code tree, and I request PMC members to give me a lazy
> consensus vote to do so.  Please +1 this email if you agree.
>
> The proposed rules of engagement are (drawn from issues raised in that
> email thread):
> 1. Commits to this branch to have the same rules as to master:  Jira, PR,
> and at least one +1 from a knowledgeable reviewer, and no -1’s.
> 2. +1 reviews may come from any participating contributor, not only
> current committers.  But commits still have to be made by a committer, so
> we don’t have to create new auth infra for this branch.
> 3. The branch should be updated from master at least every second week, or
> more frequently.  This may be adjusted to avoid disruption of work in
> progress.
> 4. PR’s to master will be posted for review as soon as self-consistent
> chunks of useful functionality are done.  The collaborators will define
> those chunks, but a rough goal is every two weeks.  The goal is to avoid
> mega-patches to review.
> 5. PR’s to master will be posted by a single developer from their home
> github repo, not directly from the speculative branch, so that
> collaborative work can proceed on the speculative branch.
> 6. The PR’s will be credited equally to all collaborators active during
> that “chunk” of work.
> 7. PR’s to master have to be reviewed and agreed to as though they were
> new patches. (The fact they were previously accepted into the speculative
> branch is at most a recommendation, not an a priori decision to let them
> into master.) The usual rules apply.  While collaborators will likely want
> to +1 such PRs, sufficient time must be provided for other community
> members to review and raise issues.
>
> Thanks,
> --Matt
>
>
>
> --

Jon

Re: [Request for Consensus Approval] dev branch for Stellar additional work

Okay, I’ll undertake to add to the committer’s guide before the first PR.

From: Otto Fowler 
Date: Wednesday, July 5, 2017 at 6:28 AM
To: "dev@metron.apache.org" , Matt Foley 

Subject: Re: [Request for Consensus Approval] dev branch for Stellar additional 
work

Just want to say, we will need updated versions of the commuter’s guide for 
doing commits and reviews to branches like this.

The current scripts we use will need to be updated ( as we go ), the we should 
at least have a plan to provide these guides before the first pr.

On July 5, 2017 at 04:40:16, Matt Foley (ma...@apache.org) wrote:

Now that METRON-877 is in, I would like to proceed with Steps 3-6 of the 
remaining work to separate out Stellar functionality as an independent module. 
A couple people have suggested that this further development should be done in 
a Metron “dev branch”, where: 
a) changes are more visible than in a single person’s private development 
branch, and 
b) work can proceed for several days or a couple weeks on a branch that the 
collaborators may choose to keep stable for the duration (ie, without 
constantly updating to master). 

This concept was discussed as a “speculative branch” in this email thread: 
https://lists.apache.org/thread.html/391e15347ad625c4aa61e81f5dd238c0acb4048b8d77f93313298263@%3Cdev.metron.apache.org%3E

but I don’t see that we ever actually changed our bylaws to mention it. 

Nevertheless, it falls within the purview of the PMC to create new branches in 
our code tree, and I request PMC members to give me a lazy consensus vote to do 
so. Please +1 this email if you agree. 

The proposed rules of engagement are (drawn from issues raised in that email 
thread): 
1. Commits to this branch to have the same rules as to master: Jira, PR, and at 
least one +1 from a knowledgeable reviewer, and no -1’s. 
2. +1 reviews may come from any participating contributor, not only current 
committers. But commits still have to be made by a committer, so we don’t have 
to create new auth infra for this branch. 
3. The branch should be updated from master at least every second week, or more 
frequently. This may be adjusted to avoid disruption of work in progress. 
4. PR’s to master will be posted for review as soon as self-consistent chunks 
of useful functionality are done. The collaborators will define those chunks, 
but a rough goal is every two weeks. The goal is to avoid mega-patches to 
review. 
5. PR’s to master will be posted by a single developer from their home github 
repo, not directly from the speculative branch, so that collaborative work can 
proceed on the speculative branch. 
6. The PR’s will be credited equally to all collaborators active during that 
“chunk” of work. 
7. PR’s to master have to be reviewed and agreed to as though they were new 
patches. (The fact they were previously accepted into the speculative branch is 
at most a recommendation, not an a priori decision to let them into master.) 
The usual rules apply. While collaborators will likely want to +1 such PRs, 
sufficient time must be provided for other community members to review and 
raise issues. 

Thanks, 
--Matt

[GitHub] metron issue #629: METRON-1012 Update Metron public web site for 0.4.0 relea...

Github user JonZeolla commented on the issue:

https://github.com/apache/metron/pull/629
  
I didn't review it, but I have no reason to hold it back.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #629: METRON-1012 Update Metron public web site for 0.4.0 relea...

Github user mattf-horton commented on the issue:

https://github.com/apache/metron/pull/629
  
Hi @JonZeolla , you're quite right, I forgot I already opened METRON-718.
Are we okay to push this patch then?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #619: METRON-939 Elasticsearch ES5 with Xshield client support

2017-07-05 Thread wardbekker

Github user wardbekker commented on the issue:

https://github.com/apache/metron/pull/619
  
@JonZeolla done. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #619: METRON-939 Elasticsearch ES5 with Xshield client support

Github user JonZeolla commented on the issue:

https://github.com/apache/metron/pull/619
  
@wardbekker Can you please merge master and deconflict?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron pull request #613: METRON-990: Clean up and organize flux properties

2017-07-05 Thread asfgit

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

FW: Runbook is ready for review

2017-07-05 Thread Rita McKissick

My apologies. I sent this doc to the wrong email alias. Please ignore this 
review request.

Rita

Rita McKissick ! Sr. Technical Writer









On 7/5/17, 6:48 AM, "Rita McKissick"  wrote:

>There are still a couple sections that are work in progress:
>
>  *   Enriching Threat Intelligence
>  *   Configuring Indexing
>
>but please feel free to comment on the entire guide:
>
>http://dev.hortonworks.com.s3.amazonaws.com/HDPDocuments/HCS1/HCS-1-trunk/bk_runbook/content/index.html
>
>I’ll need your comments by COB Friday in order to incorporate them for our 
>upcoming release.
>
>Thanks,
>
>Rita
>
>
>Rita McKissick ! Sr. Technical Writer
>
>

Re: Runbook is ready for review

2017-07-05 Thread Rita McKissick

Thank you for the catch, Otto. I will remove any references to incubating.

Rita

Rita McKissick ! Sr. Technical Writer

From: Otto Fowler
Date: Wednesday, July 5, 2017 at 6:51 AM
To: default, "dev@metron.apache.org"
Subject: Re: Runbook is ready for review

Metron has graduated, and as such any reference to Apache Metron (Incubating) 
should be just Apache Metron.

On July 5, 2017 at 09:48:37, Rita McKissick 
(rmckiss...@hortonworks.com) wrote:

There are still a couple sections that are work in progress:

* Enriching Threat Intelligence
* Configuring Indexing

but please feel free to comment on the entire guide:

http://dev.hortonworks.com.s3.amazonaws.com/HDPDocuments/HCS1/HCS-1-trunk/bk_runbook/content/index.html

I’ll need your comments by COB Friday in order to incorporate them for our 
upcoming release.

Thanks,

Rita

Rita McKissick ! Sr. Technical Writer

Runbook is ready for review

2017-07-05 Thread Rita McKissick

There are still a couple sections that are work in progress:

  *   Enriching Threat Intelligence
  *   Configuring Indexing

but please feel free to comment on the entire guide:

http://dev.hortonworks.com.s3.amazonaws.com/HDPDocuments/HCS1/HCS-1-trunk/bk_runbook/content/index.html

I’ll need your comments by COB Friday in order to incorporate them for our 
upcoming release.

Thanks,

Rita


Rita McKissick ! Sr. Technical Writer

Re: [Request for Consensus Approval] dev branch for Stellar additional work

2017-07-05 Thread zeo...@gmail.com

That all sounds pretty reasonable to me.  My biggest concern would be
attribution during step 5 - we would need to make sure it isn't squash
merged like we typically do (assuming we do properly squash merge into
the speculative
branch).  Not a big issue though, I guess, just need to make sure it isn't
overlooked.

Jon

On Wed, Jul 5, 2017 at 4:40 AM Matt Foley  wrote:

> Now that METRON-877 is in, I would like to proceed with Steps 3-6 of the
> remaining work to separate out Stellar functionality as an independent
> module.  A couple people have suggested that this further development
> should be done in a Metron “dev branch”, where:
> a) changes are more visible than in a single person’s private development
> branch, and
> b) work can proceed for several days or a couple weeks on a branch that
> the collaborators may choose to keep stable for the duration (ie, without
> constantly updating to master).
>
> This concept was discussed as a “speculative branch” in this email thread:
> https://lists.apache.org/thread.html/391e15347ad625c4aa61e81f5dd238c0acb4048b8d77f93313298263@%3Cdev.metron.apache.org%3E
> but I don’t see that we ever actually changed our bylaws to mention it.
>
> Nevertheless, it falls within the purview of the PMC to create new
> branches in our code tree, and I request PMC members to give me a lazy
> consensus vote to do so.  Please +1 this email if you agree.
>
> The proposed rules of engagement are (drawn from issues raised in that
> email thread):
> 1. Commits to this branch to have the same rules as to master:  Jira, PR,
> and at least one +1 from a knowledgeable reviewer, and no -1’s.
> 2. +1 reviews may come from any participating contributor, not only
> current committers.  But commits still have to be made by a committer, so
> we don’t have to create new auth infra for this branch.
> 3. The branch should be updated from master at least every second week, or
> more frequently.  This may be adjusted to avoid disruption of work in
> progress.
> 4. PR’s to master will be posted for review as soon as self-consistent
> chunks of useful functionality are done.  The collaborators will define
> those chunks, but a rough goal is every two weeks.  The goal is to avoid
> mega-patches to review.
> 5. PR’s to master will be posted by a single developer from their home
> github repo, not directly from the speculative branch, so that
> collaborative work can proceed on the speculative branch.
> 6. The PR’s will be credited equally to all collaborators active during
> that “chunk” of work.
> 7. PR’s to master have to be reviewed and agreed to as though they were
> new patches. (The fact they were previously accepted into the speculative
> branch is at most a recommendation, not an a priori decision to let them
> into master.) The usual rules apply.  While collaborators will likely want
> to +1 such PRs, sufficient time must be provided for other community
> members to review and raise issues.
>
> Thanks,
> --Matt
>
>
>
> --

Jon

Re: [Request for Consensus Approval] dev branch for Stellar additional work

2017-07-05 Thread Otto Fowler

Just want to say, we will need updated versions of the commuter’s guide for
doing commits and reviews to branches like this.
The current scripts we use will need to be updated ( as we go ), the we
should at least have a plan to provide these guides before the first pr.

On July 5, 2017 at 04:40:16, Matt Foley (ma...@apache.org) wrote:

Now that METRON-877 is in, I would like to proceed with Steps 3-6 of the
remaining work to separate out Stellar functionality as an independent
module. A couple people have suggested that this further development should
be done in a Metron “dev branch”, where:
a) changes are more visible than in a single person’s private development
branch, and
b) work can proceed for several days or a couple weeks on a branch that the
collaborators may choose to keep stable for the duration (ie, without
constantly updating to master).

This concept was discussed as a “speculative branch” in this email thread:
https://lists.apache.org/thread.html/391e15347ad625c4aa61e81f5dd238c0acb4048b8d77f93313298263@%3Cdev.metron.apache.org%3E
but I don’t see that we ever actually changed our bylaws to mention it.

Nevertheless, it falls within the purview of the PMC to create new branches
in our code tree, and I request PMC members to give me a lazy consensus
vote to do so. Please +1 this email if you agree.

The proposed rules of engagement are (drawn from issues raised in that
email thread):
1. Commits to this branch to have the same rules as to master: Jira, PR,
and at least one +1 from a knowledgeable reviewer, and no -1’s.
2. +1 reviews may come from any participating contributor, not only current
committers. But commits still have to be made by a committer, so we don’t
have to create new auth infra for this branch.
3. The branch should be updated from master at least every second week, or
more frequently. This may be adjusted to avoid disruption of work in
progress.
4. PR’s to master will be posted for review as soon as self-consistent
chunks of useful functionality are done. The collaborators will define
those chunks, but a rough goal is every two weeks. The goal is to avoid
mega-patches to review.
5. PR’s to master will be posted by a single developer from their home
github repo, not directly from the speculative branch, so that
collaborative work can proceed on the speculative branch.
6. The PR’s will be credited equally to all collaborators active during
that “chunk” of work.
7. PR’s to master have to be reviewed and agreed to as though they were new
patches. (The fact they were previously accepted into the speculative
branch is at most a recommendation, not an a priori decision to let them
into master.) The usual rules apply. While collaborators will likely want
to +1 such PRs, sufficient time must be provided for other community
members to review and raise issues.

Thanks,
--Matt

[GitHub] metron issue #630: METRON-1014 StellarShell class name typo

2017-07-05 Thread ottobackwards

Github user ottobackwards commented on the issue:

https://github.com/apache/metron/pull/630
  
+1 - I have been preforming this same operation in my vm's manually, this 
is the fix


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #629: METRON-1012 Update Metron public web site for 0.4.0 relea...

Github user JonZeolla commented on the issue:

https://github.com/apache/metron/pull/629
  
@mattf-horton Okay great, sounds good to me.  I did a quick search before 
opening a new JIRA and it looks like you've already addressed this in 
[METRON-718](https://issues.apache.org/jira/browse/METRON-718).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron pull request #586: METRON-508 Expand Elasticsearch templates to suppo...

2017-07-05 Thread asfgit

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #629: METRON-1012 Update Metron public web site for 0.4.0 relea...

Github user justinleet commented on the issue:

https://github.com/apache/metron/pull/629
  
@mattf-horton To the best of my knowledge, this was the last pass that gets 
rid of the remaining incubator terminology.  Only things left are old news 
items and so on that are actually from or about incubation. Thanks for taking 
care of the wiki, too.  I hadn't looked at it enough for incubating stuff.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron pull request #630: METRON-1014 StellarShell class name typo

GitHub user mattf-horton opened a pull request:

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

METRON-1014 StellarShell class name typo

## Contributor Comments
Fix a path typo

To test is trivial, but unfortunately requires building and then launching 
quick-dev or other install, then invoke the stellar shell script.  If it 
launches successfully the bug is fixed.  It currently errors on a Class Not 
Found error.

I've opened METRON-1015 to create an integration test for this issue 
(problem in the CLI independent of the Stellar executor).

## Pull Request Checklist

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? If not one needs to 
be created at [Metron 
Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel).
 
- [x] Does your PR title start with METRON- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.
- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?


### For code changes:
- [x] Have you included steps to reproduce the behavior or problem that is 
being changed or addressed?
- [x] Have you included steps or a guide to how the change may be verified 
and tested manually?
- [NA] Have you ensured that the full suite of tests and checks have been 
executed in the root incubating-metron folder via:
  ```
  mvn -q clean integration-test install && build_utils/verify_licenses.sh 
  ```

- [NA] Have you written or updated unit tests and or integration tests to 
verify your changes?
- [NA] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [x] Have you verified the basic functionality of the build by building 
and running locally with Vagrant full-dev environment or the equivalent?

### For documentation related changes: NA

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mattf-horton/metron METRON-1014

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/metron/pull/630.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #630


commit a95c8ad69185e6265f81add6bf151229bf48fec5
Author: mattf-horton 
Date:   2017-07-05T09:09:52Z

METRON-1014 StellarShell class name typo




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[Request for Consensus Approval] dev branch for Stellar additional work

Now that METRON-877 is in, I would like to proceed with Steps 3-6 of the
remaining work to separate out Stellar functionality as an independent module.
A couple people have suggested that this further development should be done in
a Metron “dev branch”, where:
a) changes are more visible than in a single person’s private development
branch, and
b) work can proceed for several days or a couple weeks on a branch that the
collaborators may choose to keep stable for the duration (ie, without
constantly updating to master).

Nevertheless, it falls within the purview of the PMC to create new branches in
our code tree, and I request PMC members to give me a lazy consensus vote to do
so. Please +1 this email if you agree.

The proposed rules of engagement are (drawn from issues raised in that email
thread):
1. Commits to this branch to have the same rules as to master: Jira, PR, and
at least one +1 from a knowledgeable reviewer, and no -1’s.
2. +1 reviews may come from any participating contributor, not only current
committers. But commits still have to be made by a committer, so we don’t have
to create new auth infra for this branch.
3. The branch should be updated from master at least every second week, or more
frequently. This may be adjusted to avoid disruption of work in progress.
4. PR’s to master will be posted for review as soon as self-consistent chunks
of useful functionality are done. The collaborators will define those chunks,
but a rough goal is every two weeks. The goal is to avoid mega-patches to
review.
5. PR’s to master will be posted by a single developer from their home github
repo, not directly from the speculative branch, so that collaborative work can
proceed on the speculative branch.
6. The PR’s will be credited equally to all collaborators active during that
“chunk” of work.
7. PR’s to master have to be reviewed and agreed to as though they were new
patches. (The fact they were previously accepted into the speculative branch is
at most a recommendation, not an a priori decision to let them into master.)
The usual rules apply. While collaborators will likely want to +1 such PRs,
sufficient time must be provided for other community members to review and
raise issues.

Thanks,
--Matt

[GitHub] metron issue #629: METRON-1012 Update Metron public web site for 0.4.0 relea...