Page History

 .

Code

CD10The project produces Open Source software, for distribution to the public at no charge. 

All of Metron source code is Open Source under under the Apache 2.0 license.  We do not charge for the software

1CD20The project's code is easily discoverable and publicly accessible.

All of Metron source code is staged in Github at the following URL: git: https://git-wip-us.apache.org/repos/asf?p=incubator-metron.git  (mirrored on github at https://github.com/apache/incubator-metron).  Metron also has a website at the following URL: http://metron.incubator.apache.org/.  A Google search for "Apache Metron" brings up these links #4 and #1 on the list respectively. 

CD30The code can be built in a reproducible way using widely available standard tools.

All of Metron source code (not inclusive of build scripts and configuration files) is can  can be built via Maven from a top-level POM file

CD40The full history of the project's code is available via a source code control system, in a way that allows any released version to be recreated.

We maintain release branches per every Metron release in source control.  The list of release branches can be referenced here: https://github.com/apache/incubator-metron/releasesgit-wip-us.apache.org/repos/asf?p=incubator-metron.git;a=heads

CD50The provenance of each line of code is established via the source code control system, in a reliable way based on strong authentication of the committer. When third-party contributions are committed, commit messages provide reliable information about the code provenance. 2

Full attribution to the committer is provided upon the merge of the pull request.  Our standard pull request process that incorporates this policy is documented here: Merging Pull Requests This is recorded in two places.  First, it is recorded when a pull request is committed.  Second, this is recorded in the JIRA workflow.

Licenses and Copyright

LC10The code is released under the Apache License, version 2.0.

All Metron code is released under the Apache 2.0 License. [TODO] Attach vote reference once a build gets approved with no conditions.  We have had 4 sanctioned Apache releases as per http://metron.apache.org/documentation/#releases

LC20Libraries that are mandatory dependencies of the project's code do not create more restrictions than the Apache License does. 3 4

...

LC50The copyright ownership of everything that the project produces is clearly defined and documented. 5

[TODO] Need to follow up to see if we need a copyright notice for things like docs? We document copyrights of all included source code in compliance with Apache licensing standards.

Releases

RE10Releases consist of source code, distributed using standard and open archive formats that are expected to stay readable in the long term. 6

...

RE50The release process is documented and repeatable to the extent that someone new to the project is able to independently generate the complete set of artifacts required for a release.

[TODO] Need to produce this documentationOur release process is documented here: Release Process

Quality

QU10The project is open and honest about the quality of its code. Various levels of quality and maturity for various modules are natural and acceptable as long as they are clearly communicated.

Metron provides instructions on how to validate and test as a part of every voting email.  Further more, there is a integration and unit test framework that runs during every Maven build to catch bugs at build time.  

Instructions on how to verify builds are provided here: [TODO] We need to establish documentation about these frameworks Verifying Builds

An email template announcing the build and providing a link to verification instructions can be found here: Build Vote Template

QU20The project puts a very high priority on producing secure software. 7

[TODO] We need to document our security guidelines As documented in our release instructions if a JIRA comes in that has security implications on Metron it is prioritized and a new build may be issued immediately upon it's resolution.  This process is documented here: Release Process

QU30The project provides a well-documented channel to report security issues, along with a documented way of responding to them. 8

[TODO] Add Metron has a security board to the incubator status websitewhere security issues can be identified and addressed.  The board as well as the instructions on how to post are documented in Metron's incubation status page located here: Metron Incubation Status

QU40The project puts a high priority on backwards compatibility and aims to document any incompatible changes and provide tools and documentation to help users transition to new features.

[TODO] Produce documentation for 0.2 to 0.3 migrationWe document incompatible changes and provide links to upgrades for every major build of Metron.  An example can be seen in our announcement of the new build here: Announcing Metron 0.3.0

QU50The project strives to respond to documented bug reports in a timely manner.

We document bugs in the Metorn JIRA Metron JIRA as soon as we find them.  The Metron JIRA can be seen here: https://issues.apache.org/jira/browse/METRON/

...

CO10The project has a well-known homepage that points to all the information required to operate according to this maturity model.

[TODO] Align our website to better correspond to the items in this entryMetron's website is http://metron.incubator.apache.org/ and Metron's wiki has additional information that can be found here: Metron Wiki

CO20The community welcomes contributions from anyone who acts in good faith and in a respectful manner and adds value to the project.

...

CO50The way in which contributors can be granted more rights such as commit access or decision power is clearly documented and is the same for all contributors.

[TODO] We need to produce this documentation This process is outlined in the Metron Bylaws and can be found here: Apache Metron Bylaws

CO60The community operates based on consensus of its members (see CS10) who have decision power. Dictators, benevolent or not, are not welcome in Apache projects.

...

CS30Documented voting rules are used to build consensus when discussion is not sufficient. 10

[TODO] Need to produce this documentation Voting rules are documented in the Metron Bylaws located here: Apache Metron Bylaws

CS40In Apache projects, vetoes are only valid for code commits and are justified by a technical explanation, as per the Apache voting rules defined in CS30.

[TODO] We need to clearly state this in our bylaws A specific provision for this was recently added into the Metron Bylaws and was voted on and approved by the Metron community.  The document is located here: Apache Metron Bylaws

CS50All "important" discussions happen asynchronously in written form on the project's main communications channel. Offline, face-to-face or private discussions 11 that affect the project are also documented on that channel.

...