You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@metron.apache.org by ot...@apache.org on 2018/10/24 15:04:27 UTC
[38/51] [abbrv] metron git commit: METRON-1799 Remove outdated bylaws
from site. (justinleet) closes apache/metron#1216
METRON-1799 Remove outdated bylaws from site. (justinleet) closes apache/metron#1216
Project: http://git-wip-us.apache.org/repos/asf/metron/repo
Commit: http://git-wip-us.apache.org/repos/asf/metron/commit/9b671005
Tree: http://git-wip-us.apache.org/repos/asf/metron/tree/9b671005
Diff: http://git-wip-us.apache.org/repos/asf/metron/diff/9b671005
Branch: refs/heads/feature/METRON-1090-stellar-assignment
Commit: 9b6710053894d8a39880cb8157a0e603ed542cb7
Parents: f153375
Author: justinleet <ju...@gmail.com>
Authored: Thu Oct 11 08:41:23 2018 -0400
Committer: leet <le...@apache.org>
Committed: Thu Oct 11 08:41:23 2018 -0400
----------------------------------------------------------------------
site/develop/bylaws.md | 281 --------------------------------------------
site/develop/coding.md | 34 ------
site/develop/index.md | 61 ----------
3 files changed, 376 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/metron/blob/9b671005/site/develop/bylaws.md
----------------------------------------------------------------------
diff --git a/site/develop/bylaws.md b/site/develop/bylaws.md
deleted file mode 100644
index a8fc5fb..0000000
--- a/site/develop/bylaws.md
+++ /dev/null
@@ -1,281 +0,0 @@
----
-layout: page
-title: Apache Metron Bylaws
----
-
-## Introduction
-
-This document defines the bylaws under which the Apache Metron project
-operates. It defines the roles and responsibilities of the project,
-who may vote, how voting works, how conflicts are resolved, etc.
-
-Metron is a project of the Apache Software Foundation (ASF) and the foundation
-holds the trademark on the name "Metron" and copyright on the combined
-code base. The [Apache Foundation
-FAQ](http://www.apache.org/foundation/faq.html) and
-[How-It-Works](http://www.apache.org/foundation/how-it-works.html)
-explain the operation and background of the foundation.
-
-Apache has a [code of
-conduct](http://www.apache.org/foundation/policies/conduct.html) that
-it expects its members to follow. In particular:
-
-* Be **open and welcoming**. It is important that we grow and
- encourage the community of users and developers for our project.
-
-* Be **collaborative**. Working together on the open mailing lists and
- bug database to make decisions helps the project grow.
-
-* Be **respectful** of others. Everyone is volunteering their time and
- efforts to work on this project. Please be respectful of everyone
- and their views.
-
-Metron is typical of Apache projects in that it operates under a set of
-principles, known collectively as the "Apache Way". If you are new to
-Apache development, please refer to
-[this](http://www.apache.org/foundation/how-it-works.html) for more
-information on how Apache projects operate.
-
-## Roles and Responsibilities
-
-Apache projects define a set of roles with associated rights and
-responsibilities. These roles govern what tasks an individual may
-perform within the project. The roles are defined in the following
-sections.
-
-### Users
-
-The most important participants in the project are people who use our
-software. The majority of our developers start out as users and guide
-their development efforts from the user's perspective. Users
-contribute to the Apache projects by providing feedback to developers
-in the form of bug reports and feature suggestions. As well, users
-participate in the Apache community by helping other users on mailing
-lists and user support forums.
-
-### Contributors
-
-Contributors include all of the volunteers who donate time, code,
-documentation,
-or resources to the Metron Project. A contributor that makes sustained,
-welcome contributions to the project may be invited to become a
-committer, though the exact timing of such invitations depends on many
-factors.
-
-### Committers
-
-The project's committers are responsible for the project's technical
-management. Committers have the right to commit to the project's git
-repository. Committers may cast binding votes on any technical
-discussion.
-
-Committer access is by invitation only and must be approved by
-consensus approval of the active Project Management Committee (PMC)
-members.
-
-If a committer wishes to leave the project or does not contribute to
-the project in any form for six months, the PMC may make them emeritus.
-Emeritus committers lose their ability to commit code or cast binding
-votes. An emeritus committer may
-request reinstatement of commit access from the PMC. Such
-reinstatement is subject to consensus approval of active PMC members.
-
-All Apache committers are required to have a signed [Individual
-Contributor License
-Agreement](https://www.apache.org/licenses/icla.txt) (ICLA) on file
-with the Apache Software Foundation. There is a [Committer
-FAQ](http://www.apache.org/dev/committers.html) which provides more
-details on the requirements for Committers.
-
-A committer who makes a
-sustained contribution to the project may be invited to become a
-member of the PMC. The form of contribution
-is not limited to code. It can also include code review, helping out
-users on the mailing lists, documentation, testing, etc.
-
-### Release Manager
-
-A Release Manager (RM) is a committer who volunteers to produce a
-Release Candidate. The RM shall publish a Release Plan on the
-dev mailing list stating the branch from which they intend to
-make a Release Candidate.
-
-### Project Management Committee
-
-The Project Management Committee (PMC) for Apache Metron was created by
-the Apache Board in December 2015 when Metron moved out of Cisco's OpenSOC
-project and became an incubated project at Apache.
-The PMC is responsible to the board and
-the ASF for the management and oversight of the Apache Metron
-codebase. The responsibilities of the PMC include
-
- * Deciding what is distributed as products of the Apache Metron
- project. In particular all releases must be approved by the PMC.
-
- * Maintaining the project's shared resources, including the codebase
- repository, mailing lists, and websites.
-
- * Speaking on behalf of the project.
-
- * Resolving license disputes regarding products of the project
-
- * Nominating new PMC members and committers
-
- * Maintaining these bylaws and other guidelines of the project
-
-Membership of the PMC is by invitation only and must be approved by a
-consensus approval of active PMC members.
-
-A PMC member is considered
-emeritus by their own declaration or by not contributing in any form
-to the project for over six months. An emeritus member may request
-reinstatement to the PMC. Such reinstatement is subject to consensus
-approval of the active PMC members.
-
-The chair of the PMC is appointed by the ASF board. The chair is an
-office holder of the Apache Software Foundation (Vice President,
-Apache Metron) and has primary responsibility to the board for the
-management of the project within the scope of the Metron PMC. The
-chair reports to the board quarterly on developments within the Metron
-project.
-
-When the project desires a new PMC chair, the PMC votes to recommend a
-new chair using [Single Transferable
-Vote](http://wiki.apache.org/general/BoardVoting) voting. The decision
-must be ratified by the Apache board.
-
-## Decision Making
-
-Within the Metron project, different types of decisions require
-different forms of approval. For example, the previous section
-describes several decisions which require "consensus approval."
-This section defines how voting is performed, the types of
-approvals, and which types of decision require which type of approval.
-
-### Voting
-
-Decisions regarding the project are made by votes on the primary
-project development mailing list (dev@Metron.apache.org). Where
-necessary, PMC voting may take place on the private Metron PMC mailing
-list. Votes are clearly indicated by subject line starting with
-[VOTE]. Votes may contain multiple items for approval and these should
-be clearly separated. Voting is carried out by replying to the vote
-mail. Voting may take five flavors:
-
-* **+1** -- "Yes," "Agree," or "the action should be performed." In general,
- this vote also indicates a willingness on the behalf of the voter in
- "making it happen."
-
-* **+0** -- This vote indicates a willingness for the action under
- consideration to go ahead. The voter, however, will not be able to
- help.
-
-* **0** -- The voter is neutral on the topic under discussion.
-
-* **-0** -- This vote indicates that the voter does not, in general, agree
- with the proposed action but is not concerned enough to prevent the
- action going ahead.
-
-* **-1** -- This is a negative vote. On issues where consensus is required,
- this vote counts as a veto. All vetoes must contain an explanation
- of why the veto is appropriate. Vetoes with no explanation are
- void. It may also be appropriate for a -1 vote to include an
- alternative course of action.
-
-All participants in the Metron project are encouraged to show their
-agreement for or against a particular action by voting, regardless of
-whether their vote is binding. Nonbinding votes are useful for
-encouraging discussion and understanding the scope of opinions within
-the project.
-
-### Approvals
-
-These are the types of approvals that can be sought. Different actions
-require different types of approvals.
-
-* **Consensus Approval** -- Consensus approval requires 3 binding +1
- votes and no binding vetoes.
-
-* **Lazy Consensus** -- Lazy consensus requires at least one +1 vote and
- no -1 votes ('silence gives assent').
-
-* **Lazy Majority** -- A lazy majority vote requires 3 binding +1 votes
- and more binding +1 votes than -1 votes.
-
-* **Lazy 2/3 Majority** -- Lazy 2/3 majority votes requires at least 3
- votes and twice as many +1 votes as -1 votes.
-
-### Vetoes
-
-A valid, binding veto cannot be overruled. If a veto is cast, it must
-be accompanied by a valid reason explaining the reasons for the
-veto. The validity of a veto, if challenged, can be confirmed by
-anyone who has a binding vote. This does not necessarily signify
-agreement with the veto - merely that the veto is valid. If you
-disagree with a valid veto, you must lobby the person casting the veto
-to withdraw their veto. If a veto is not withdrawn, any action that
-has already been taken must be reversed in a timely manner.
-
-### Actions
-
-This section describes the various actions which are undertaken within
-the project, the corresponding approval required for that action and
-those who have binding votes over the action.
-
-#### Code Change
-
-A change made to a codebase of the project requires *lazy consensus*
-of active committers other than the author of the patch. The code can
-be committed after the first +1.
-
-#### Product Release
-
-To make a release, the release manager creates a release candidate and
-a vote requiring a *lazy majority* of the active PMC members is
-required. Once the vote passes, the release candidate becomes an
-official release.
-
-#### Adoption of New Codebase
-
-When the codebase for an existing, released product is to be replaced
-with an alternative codebase, it requires a *lazy 2/3 majority* of PMC
-members. This also covers the creation of new sub-projects and
-submodules within the project.
-
-#### New Committer
-
-When a new committer is proposed for the project, *consensus approval*
-of the active PMC members is required.
-
-#### New PMC Member
-
-To promote a committer to a PMC member requires *consensus approval*
-of active PMC members.
-
-If the vote passes, the Apache Board must be notified to make the change
-official.
-
-#### Committer Removal
-
-Removal of commit privileges requires a *lazy 2/3 majority* of active
-PMC members.
-
-#### PMC Member Removal
-
-Removing a PMC member requires a *lazy 2/3 majority* of active PMC
-members, excluding the member in question.
-
-If the vote passes, the Apache Board must be notified to make the change
-official.
-
-#### Modifying Bylaws
-
-Modifying this document requires a *lazy majority* of active PMC members.
-
-### Voting Timeframes
-
-Votes are open for a minimum period of 72 hours to allow all active
-voters time to consider the vote. For holiday weekends or conferences,
-consider using a longer vote window. Votes relating to code changes are
-not subject to a strict timetable but should be made as timely as
-possible.
http://git-wip-us.apache.org/repos/asf/metron/blob/9b671005/site/develop/coding.md
----------------------------------------------------------------------
diff --git a/site/develop/coding.md b/site/develop/coding.md
deleted file mode 100644
index 78c7e27..0000000
--- a/site/develop/coding.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-layout: page
-title: Coding Guidelines
----
-
-## General rules
-
-* All files must have an Apache copyright header at the top of the file.
-* Code should be removed rather than commented out.
-* All public functions should have javadoc comments.
-* Always use braces to surround branches.
-* try-finally should be avoided.
-
-## Formatting
-
-* All files must have an 80 character maximum line length.
-* Indentation should be 2 spaces.
-* Files should use spaces instead of tabs.
-* Wrapping lines
- * Break after a comma.
- * Break before an operator.
- * Prefer higher-level breaks to lower-level breaks.
- * Align the new line with beginning of the expression at the same level
- on the previous line.
- * If the above rules lead to confusing code, just indent 8 spaces.
-* One variable declaration per a line.
-
-## Naming
-
-* Packages should be all lowercase.
- * Java code should be in `org.apache.,metron`, except for compatibility classes
-* Classes should be in mixed case.
-* Variables should be in camel case.
-* Constants should be in upper case.
http://git-wip-us.apache.org/repos/asf/metron/blob/9b671005/site/develop/index.md
----------------------------------------------------------------------
diff --git a/site/develop/index.md b/site/develop/index.md
deleted file mode 100644
index 7db04fa..0000000
--- a/site/develop/index.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-layout: page
-title: Developing
----
-
-Information about the Metron project that is most important for
-developers working on the project. The project has created
-[bylaws](bylaws.html) for itself.
-
-## Project Members
-
-Name | Apache Id | Role
-:---------------------- | :------------- | :---
-Owen O'Malley | omalley | PMC
-Jim Baker | jimbaker | PMC
-Mark Bittmann | mbittmann | PMC
-Sheetal Dolas | sheetal_dolas | PMC
-P. Taylor Goetz | ptgoetz | PMC
-Brad Kolarov | billie | PMC
-Dave Hirko | dbhirko | PMC
-Larry McCay | lmccay | PMC
-Charles Porter | cporter | PMC
-James Sirota | jsirota | PMC
-Casey Stella | cestella | PMC
-Vinod Kumar Vavilapalli | vinodkv | PMC
-George Vetticaden | gvetticaden | PMC
-
-## Mailing Lists
-
-There are several development mailing lists for Metron
-
-* [dev@metron.apache.org](mailto:dev@metron.apache.org) - Development discussions
- with archive [here](https://mail-archives.apache.org/mod_mbox/metron-dev/)
-* [issues@metron.apache.org](mailto:issues@metron.apache.org) - Bug tracking
- with archive [here](https://mail-archives.apache.org/mod_mbox/metron-issues/)
-* [commits@metron.apache.org](mailto:commits@metron.apache.org) - Git tracking
- with archive [here](https://mail-archives.apache.org/mod_mbox/metron-commits/)
-
-You can subscribe to the lists by sending email to
-*list*-subscribe@metron.apache.org and unsubscribe by sending email to
-*list*-unsubscribe@metron.apache.org.
-
-## Source code
-
-Metron uses git for version control. Get the source code:
-
-`% git clone https://git-wip-us.apache.org/repos/asf/metron.git`
-
-The important branches are:
-
-* [master](https://github.com/apache/metron/tree/master) -
- The trunk for all developement
-* [asf-site](https://github.com/apache/metron/tree/asf-site) -
- The pages that are deployed to https://metron.apache.org/
-
-Please check our [coding guidelines](/develop/coding.html).
-
-## Reviews
-
-All code must be +1'ed by a committer other than the author prior to its
-commit.