Hi all,
I am Pushpitha Dilhan and I am a final year undergraduate majoring Computer
Science. I would like to contribute Apache Metron and hope to have guidance
for a start.
Thank you
Pushpitha
Github user ottobackwards commented on a diff in the pull request:
https://github.com/apache/metron/pull/872#discussion_r157332543
--- Diff:
metron-analytics/metron-statistics/src/main/java/org/apache/metron/statistics/informationtheory/InformationTheoryUtil.java
---
@@ -0,0 +1,52
Github user ottobackwards commented on a diff in the pull request:
https://github.com/apache/metron/pull/872#discussion_r157332057
--- Diff:
metron-analytics/metron-statistics/src/main/java/org/apache/metron/statistics/informationtheory/InformationTheoryUtil.java
---
@@ -0,0 +1,52
GitHub user cestella opened a pull request:
https://github.com/apache/metron/pull/872
METRON-1366: Add an entropy stellar function
## Contributor Comments
Trending entropy for various volumetric statistics (e.g. netflow data) has
been a useful metric for intrusion detection (see
Great guys,
I’m going to leave the call OPEN for ideas, but at this point let’s say we
are going to schedule it for that time.
I will send the announce when I hear back form James about the room
On December 15, 2017 at 15:44:59, Michael Miklavcic (
michael.miklav...@gmail.com) wrote:
Sounds goo
GitHub user cestella opened a pull request:
https://github.com/apache/metron/pull/871
METRON-1365: Allow PROFILE_GET to return a default value for a profile and
entity that does not have a value written.
## Contributor Comments
Right now the profiler is a sparse system, namely i
Yeah, that might work too. Let's also not forget otto's scripting around
release activity: https://github.com/ottobackwards/Metron-and-Nifi-
Scripts/blob/master/metron/metron-rc-check
We seem to be accumulating a lot of automation to do this, which is great.
On Fri, Dec 15, 2017 at 2:30 PM, Matt
GitHub user cestella opened a pull request:
https://github.com/apache/metron/pull/870
METRON-1364: Add an implementation of Robust PCA outlier detection
## Contributor Comments
With short circuiting in Stellar, we have the opportunity to delve into
more computationally intensive
Github user JonZeolla commented on a diff in the pull request:
https://github.com/apache/metron/pull/865#discussion_r157303681
--- Diff: bundles-maven-plugin/README.md ---
@@ -20,7 +20,9 @@ Apache Metron Bundles Maven Plugin helps to build Bundles
Archives to support th
Sounds good Otto. We probably also want to touch on the ES 5.6 upgrade
along with our current release status and short-term release roadmap that
Nick Allen has been guiding.
On Fri, Dec 15, 2017 at 9:02 AM, Laurens Vets wrote:
> I'll try to attend :)
>
>
> On 2017-12-14 12:43, Otto Fowler wrote:
Perhaps under “build_utils” we should add a subdirectory for “release_utils”.
From: Casey Stella
Date: Friday, December 15, 2017 at 10:50 AM
To: "dev@metron.apache.org"
Cc: Matt Foley
Subject: Re: [DISCUSS] Upcoming Release
That script seems great, nick! Perhaps we should adjust the wiki arou
That script seems great, nick! Perhaps we should adjust the wiki around
releases to point to it? Thoughts?
On Fri, Dec 15, 2017 at 1:47 PM, Nick Allen wrote:
> Thanks, Matt.
>
> Maybe you already have something that does this. I wrote a quick script
> that validates each JIRA since the last r
Thanks, Matt.
Maybe you already have something that does this. I wrote a quick script
that validates each JIRA since the last release tag to make sure they are
marked "Done" and with the correct fix version. I would expect that for
the next release, each JIRA should have status="Done", fix-versi
Also, METRON-1349 [1] was merged into master, but I am not sure if that
will be included in the RC. So I resolved it and marked it as "Next + 1".
[1] https://issues.apache.org/jira/browse/METRON-1349
On Fri, Dec 15, 2017 at 12:14 PM, Nick Allen wrote:
> Hi Matt -
>
> I just updated like 15+ JI
Hi Nick,
Good timing, you’ve saved me some work! :-)
Origin of the list: The approach was defined before I started managing
releases, but I think it’s a reasonable approach. It’s specified in our
Release Process document,
https://cwiki.apache.org/confluence/display/METRON/Release+Process , St
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/840
Just a status update on this. We're currently waiting for 0.4.2 to roll out
before this gets committed. We definitely want more eyes and testing on this PR
considering its breadth and size. We do no
It would almost seem like this is a contrib or incubating effort then no?
You didn’t have to write that Ubuntu guide for nothing.
Maybe we should be more explicit in that way with regards to support.
When we have it fully supported it can ‘graduate’ to the main
metron-deployment.
On December 15
Hi Matt -
I just updated like 15+ JIRAs of my own JIRAs that I completed and merged,
but failed to mark as resolved. All of these will be included in 0.4.2. I
updated each to be "fixed" in version 0.4.2 and marked as resolved.
Hopefully the next RC will report those as fixed.
(Q) Where does the
> It might be worthwhile constructing a JIRA in apache to capture the
follow-on
tasks required to bring Ubuntu into a status where it's more prominent in
our testing cycle.
Agreed. I can take care of that.
On Fri, Dec 15, 2017 at 10:54 AM, Casey Stella wrote:
> Nick is right that the ASF
Github user justinleet commented on a diff in the pull request:
https://github.com/apache/metron/pull/869#discussion_r157238284
--- Diff: metron-deployment/README.md ---
@@ -1,175 +1,127 @@
-# Overview
-This set of playbooks can be used to deploy an Ambari-managed Hadoop
cl
Yeah, I definitely agree with folding testing Ubuntu into an RC. It would
be nice if we could fold that testing into a schedule, e.g. weekly, to
avoid unpleasant surprises at RC time. Not really sure what the best way
to go about that would be. I think a Jira on the testing topic is a good
idea.
I'll try to attend :)
On 2017-12-14 12:43, Otto Fowler wrote:
Dev Community Meeting Call
I would like to propose a developer community meeting.
I propose that we set the meeting early next week, and will throw out
Monday, December 18th at 09:30AM PST, 12:30 on the East Coast and 5:30
in
Lond
Nick is right that the ASF does not provide support in an explicit way
(i.e. there are no pathways to get *prioritized* support via SLAs, etc.),
but it is expected that apache projects provide support via mailing lists
and answered by volunteers. Specifically, this is the crux of the
"community ov
> The end goal is Ubuntu Ambari + Deb and full-dev-ubuntu right?
That list sounds good to me.
(Plus, some way of dealing with Justin's point about support.)
On Fri, Dec 15, 2017 at 10:11 AM Otto Fowler
wrote:
> I’m ok if it is not. Suggesting because it is a series of prs.
>
> The end goal i
That sounds good, Justin. It's a completely valid point. I just wasn't
sure how far we needed to take it.
Is there anything I can do in my current open PRs to address this concern?
* https://github.com/apache/metron/pull/868
* https://github.com/apache/metron/pull/869
Another alternative would
By 'direct support" I just meant that it becomes an installation target we
semi-actively maintain a specific installation method for.
Right now we don't need to communicate that all because we don't provide
anything other RPMs. The cutoff is implicit: There's convenience RPMs you
can build, or yo
I’m ok if it is not. Suggesting because it is a series of prs.
The end goal is Ubuntu Ambari + Deb and full-dev-ubuntu right?
On December 15, 2017 at 10:03:23, Nick Allen (n...@nickallen.org) wrote:
> This seems like a feature branch candidate.
Personally, I don't see the need for a feature bra
> This seems like a feature branch candidate.
Personally, I don't see the need for a feature branch on this one. It
won't involve big, architectural changes. The touch points are
constrained. Everything that we currently have will continue to work as it
always had after each PR. If you feel st
> I suggest we make sure to very explicitly document what the level of
support, testing, etc. for everything is. If we're not requiring
everything to be tested against Ubuntu, we should make sure to document
exactly what the difference in expectation is along with it being in some
categorization t
I created a ticket, https://issues.apache.org/jira/browse/METRON-1363 to
track this. I also noticed that we might be able to swipe from Nifi.
Looks like they generate a nice page for their stuff based on annotations
and we may be able to adapt it to what we have. I haven't looked at their
code at
Github user JonZeolla commented on a diff in the pull request:
https://github.com/apache/metron/pull/865#discussion_r157196243
--- Diff: bundles-maven-plugin/README.md ---
@@ -0,0 +1,230 @@
+
+# Apache Metron Bundle Maven Plugin
+
+Apache Metron Bundles Maven Plugin
Github user JonZeolla commented on a diff in the pull request:
https://github.com/apache/metron/pull/865#discussion_r157196009
--- Diff:
metron-bundles/bundles-lib/src/main/java/org/apache/metron/bundles/VfsBundleClassLoaderResource.java
---
@@ -0,0 +1,110 @@
+/*
+ * Licen
Github user JonZeolla commented on a diff in the pull request:
https://github.com/apache/metron/pull/865#discussion_r157196275
--- Diff: bundles-maven-plugin/README.md ---
@@ -0,0 +1,230 @@
+
+# Apache Metron Bundle Maven Plugin
+
+Apache Metron Bundles Maven Plugin
Github user JonZeolla commented on a diff in the pull request:
https://github.com/apache/metron/pull/865#discussion_r157195764
--- Diff: metron-bundles/bundles-lib/README.md ---
@@ -0,0 +1,213 @@
+# Apache Metron Bundles
+
+Apache Metron Bundles and this documentation ar
Github user JonZeolla commented on a diff in the pull request:
https://github.com/apache/metron/pull/865#discussion_r157196122
--- Diff: bundles-maven-plugin/NOTICE ---
@@ -0,0 +1,8 @@
+Apache NiFi
+Copyright 2014-2017 The Apache Software Foundation
+
+Apache Metron
Github user JonZeolla commented on a diff in the pull request:
https://github.com/apache/metron/pull/865#discussion_r157196527
--- Diff: metron-bundles/bundles-lib/pom.xml ---
@@ -0,0 +1,185 @@
+
+
+
+http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/
Github user JonZeolla commented on a diff in the pull request:
https://github.com/apache/metron/pull/865#discussion_r157196342
--- Diff: bundles-maven-plugin/pom.xml ---
@@ -0,0 +1,328 @@
+
+
+http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSche
Github user JonZeolla commented on a diff in the pull request:
https://github.com/apache/metron/pull/865#discussion_r157197191
--- Diff: bundles-maven-plugin/README.md ---
@@ -0,0 +1,230 @@
+
+# Apache Metron Bundle Maven Plugin
+
+Apache Metron Bundles Maven Plugin
Github user JonZeolla commented on a diff in the pull request:
https://github.com/apache/metron/pull/865#discussion_r157196478
--- Diff: bundles-maven-plugin/pom.xml ---
@@ -0,0 +1,328 @@
+
+
+http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSche
Github user JonZeolla commented on a diff in the pull request:
https://github.com/apache/metron/pull/865#discussion_r157196378
--- Diff: bundles-maven-plugin/pom.xml ---
@@ -0,0 +1,328 @@
+
+
+http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSche
Github user JonZeolla commented on a diff in the pull request:
https://github.com/apache/metron/pull/865#discussion_r157194648
--- Diff: bundles-maven-plugin/README.md ---
@@ -0,0 +1,230 @@
+
+# Apache Metron Bundle Maven Plugin
+
+Apache Metron Bundles Maven Plugin
I like your list of potential topics. I'm also in to attend - that time
works well for me.
I would be interested in talking about our release process, as I would like
to suggest that we formalize upgrade and installation instructions to be
included as a part of a release, and talk through any con
If we start adding direct support for systems other than CentOS (which I'm
in favor of), I suggest we make sure to very explicitly document what the
level of support, testing, etc. for everything is.
If we're not requiring everything to be tested against Ubuntu, we should
make sure to document exa
43 matches
Mail list logo