Ok. just made the last of the changes.  Putting it up for a vote...

Thanks for your comments, guys.

James 

17.01.2017, 15:17, "Matt Foley" <ma...@apache.org>:
> Sure, sounds fine to me.
>
> On 1/17/17, 1:03 PM, "Casey Stella" <ceste...@gmail.com> wrote:
>
>     We haven't actually bitten off the "publishing maven artifacts" just yet,
>     so I can't say that I have a good idea in my head what the detailed steps
>     are going to be. If we think that it's a good idea, I can release them and
>     figure out the steps during our next release and then vote on a
>     modification to this doc afterwards. Thoughts?
>
>     Casey
>
>     On Tue, Jan 17, 2017 at 3:43 PM, Matt Foley <ma...@apache.org> wrote:
>
>     > Casey and James,
>     > Do we also want to include in the Release Process that we publish Maven
>     > artifacts? The (detailed) procedures for Apache conformance
>     > are in http://www.apache.org/dev/publishing-maven-artifacts.html
>     >
>     > This probably wants to be integrated with our build tools.
>     >
>     > This is optional, so we could leave it for later.
>     >
>     > Thanks,
>     > --Matt
>     >
>     >
>     >
>     > On 1/17/17, 12:33 PM, "Casey Stella" <ceste...@gmail.com> wrote:
>     >
>     > Larry,
>     >
>     > Thanks for the info. In that case, then the following passage:
>     >
>     > > Now, we must grab the release candidate binary from the github
>     > releases
>     > > page (https://github.com/apache/incubator-metron/releases). In our
>     > case,
>     > > for RC1, that would be
>     > > https://github.com/apache/incubator-metron/archive/
>     > apache-metron-0.[FR++].0-rc1-incubating.tar.gz We
>     > > will refer to this as the release candidate tarball.
>     >
>     >
>     > Should be replaced with:
>     >
>     > > Now we must create the release candidate tarball. From the apache
>     > repo,
>     > > you should run:
>     > > git archive --prefix=apache-metron-0.[FR++].0-rc1-incubating/
>     > > apache-metron-0.[FR++].0-rc1-incubating | gzip >
>     > > apache-metron-0.[FR++].0-rc-incubating.tar.gz We will refer to
>     > this as the
>     > > release candidate tarball.
>     >
>     >
>     > On Tue, Jan 17, 2017 at 3:20 PM, larry mccay <lmc...@apache.org>
>     > wrote:
>     >
>     > > It is technically a violation of apache release policy to build
>     > releases in
>     > > such a way [1]:
>     > >
>     > > MUST RELEASES BE BUILT ON HARDWARE OWNED AND CONTROLLED BY THE
>     > COMMITTER?
>     > > <http://www.apache.org/dev/release.html#owned-controlled-hardware>
>     > >
>     > > Strictly speaking, releases must be verified
>     > > <https://svn.apache.org/repos/private/committers/tools/
>     > > releases/compare_dirs.pl>
>     > > on
>     > > hardware owned and controlled by the committer. That means hardware
>     > the
>     > > committer has physical possession and control of and exclusively full
>     > > administrative/superuser access to. That's because only such
>     > hardware is
>     > > qualified to hold a PGP private key, and the release should be
>     > verified on
>     > > the machine the private key lives on or on a machine as trusted as
>     > that.
>     > >
>     > > Practically speaking, when a release consists of anything beyond an
>     > archive
>     > > (e.g., tarball or zip file) of a source control tag, the only
>     > practical way
>     > > to validate that archive is to build it locally; manually inspecting
>     > > generated files (especially binary files) is not feasible. So,
>     > basically,
>     > > "Yes".
>     > >
>     > > *Note: This answer refers to the process used to produce a release
>     > artifact
>     > > from a source control tag. It does not refer to testing that
>     > artifact for
>     > > technical quality.*
>     > >
>     > >
>     > > Knox is still using the archive from a jenkins build and is also out
>     > of
>     > > compliance.
>     > >
>     > > We will need to eventually change this approach as well.
>     > >
>     > > The threat is that someone could compromise such a remote system in
>     > a way
>     > > that adds additional classes or alters the code in someway that the
>     > project
>     > > will then be propagating this compromised binary under the Apache
>     > brand.
>     > >
>     > >
>     > > 1. http://www.apache.org/dev/release.html#owned-controlled-hardware
>     > >
>     > > On Tue, Jan 17, 2017 at 2:43 PM, Casey Stella <ceste...@gmail.com>
>     > wrote:
>     > >
>     > > > Hey Matt,
>     > > >
>     > > > Github actually constructs the tarball for us using git archive
>     > (for
>     > > every
>     > > > tag, for that matter). We don't explicitly push any tarball to
>     > github.
>     > > > The reason why we pull the tarball from github directly is that we
>     > ship a
>     > > > .gitattributes to define what gets put in the tarball. (we don't
>     > ship the
>     > > > site for instance). This was just easier to describe than to walk
>     > > through
>     > > > using git archive. I don't think it's hurting anything
>     > necessarily, but
>     > > I
>     > > > might be wrong.
>     > > >
>     > > > Regarding Step 7, that can be made explicit, but the link is part
>     > of the
>     > > > VOTE template.
>     > > >
>     > > > Regarding maintenance releases, 1 and 2 may be skipped for a
>     > maintenance
>     > > > release, but the rest really should be followed. It's a release
>     > and must
>     > > > abide by apache requirements, I think. Maybe the mentors could
>     > chime in,
>     > > > though.
>     > > >
>     > > > Regarding Security break-fix, I'm not sure. Perhaps the mentors
>     > can
>     > > chime
>     > > > in?
>     > > >
>     > > > Casey
>     > > >
>     > > > On Mon, Jan 16, 2017 at 4:05 PM, Matt Foley <ma...@apache.org>
>     > wrote:
>     > > >
>     > > > > Overall, a great contribution. I suspect that as the next couple
>     > > Release
>     > > > > Managers go thru it, they’ll find various glitches to clean up,
>     > but
>     > > > that’s
>     > > > > fine.
>     > > > > Bravo especially for the last couple paragraphs (Ensuring
>     > Consistency
>     > > > > between Feature and Maint Releases), which are very good.
>     > > > >
>     > > > > One major issue: Step 4 says:
>     > > > > >> Now, we must grab the release candidate binary from the github
>     > > > releases
>     > > > > page (https://github.com/apache/incubator-metron/releases).
>     > > > >
>     > > > > Missing step! How did the tarball get there?
>     > > > >
>     > > > > Also, I don’t think the tarball should be first pushed to
>     > github. What
>     > > > > benefit does this provide, vs just pushing directly to the dev
>     > repo (
>     > > > > https://dist.apache.org/repos/dist/dev/incubator/metron )?
>     > > > >
>     > > > > Step 7 should state that the call for vote will include a link
>     > to the
>     > > RC
>     > > > > release in the dev repo.
>     > > > >
>     > > > > >>Creating a Maintenance Release
>     > > > > >> … if a critical JIRA comes in that requires an immediate
>     > patch we
>     > > may
>     > > > > forego steps 2-5 …
>     > > > >
>     > > > > Eh? I can see skipping steps 1 and 2, and abbreviating steps 5
>     > and 6,
>     > > > but
>     > > > > steps 3 and 4 are purely mechanical and seem needed by
>     > definition to
>     > > > make a
>     > > > > release. Am I missing something? Perhaps the step # references
>     > are
>     > > > from a
>     > > > > prior draft?
>     > > > >
>     > > > > Also, regarding steps 7 and 8 (the votes), are Security break-fix
>     > > > releases
>     > > > > different in terms of voting requirements for Apache?
>     > > > >
>     > > > > Thanks,
>     > > > > --Matt
>     > > > >
>     > > > >
>     > > > > On 1/16/17, 12:03 PM, "James Sirota" <jsir...@apache.org> wrote:
>     > > > >
>     > > > > If no one has additional comments on this document i'll go
>     > ahead
>     > > and
>     > > > > put it up for a vote...
>     > > > > https://cwiki.apache.org/confluence/pages/viewpage.
>     > > > > action?pageId=66854770
>     > > > >
>     > > > > 10.01.2017, 12:50, "James Sirota" <jsir...@apache.org>:
>     > > > > > Hi Larry,
>     > > > > >
>     > > > > > Thanks for the comments. I beefed up the technical
>     > section. How
>     > > > does
>     > > > > this look?
>     > > > > >
>     > > > > > https://cwiki.apache.org/confluence/pages/viewpage.
>     > > > > action?pageId=66854770
>     > > > > >
>     > > > > > 0.[FR++].0Metron Release Types
>     > > > > > There are two types of Metron releases:
>     > > > > > Feature Release (FR) - this is a release that has a
>     > significant
>     > > > step
>     > > > > forward in feature capability and is denoted by an upgrade of the
>     > > second
>     > > > > digit
>     > > > > > Maintenance Release (MR) - this is a set of patches and
>     > fixes
>     > > that
>     > > > > are issued following the FR and is denoted by an upgrade of the
>     > third
>     > > > digit
>     > > > > > Release Naming Convention
>     > > > > > Metron build naming convention is as follows: 0.[FR].[MR].
>     > We
>     > > keep
>     > > > > the 0. notation to signify that the project is still under active
>     > > > > development and we will hold a community vote to go to 1.x at a
>     > future
>     > > > time
>     > > > > > Initiating a New Metron Release
>     > > > > > Immediately upon the release of the previous Metron release
>     > > create
>     > > > > two branches: FR ++ and MR. Create the FR++ branch by
>     > incrementing the
>     > > > > second digit like so 0.[FR++].0. Create the MR branch for the
>     > previous
>     > > > > Metron release by incrementing the second digit of the previous
>     > release
>     > > > > like so 0.[FR].[MR]. All patches to the previous Metron release
>     > will be
>     > > > > checked in under the MR branch and where it makes sense also
>     > under the
>     > > FR
>     > > > > branch. All new features will be checked in under the FR branch.
>     > > > > > Creating a Feature Release
>     > > > > > Step 1 - Initiate a discuss thread
>     > > > > > Prior to the release The Release manager should do the
>     > following
>     > > > > (preferably a month before the release):
>     > > > > > Make sure that the list of JIRAs slated for the release
>     > > accurately
>     > > > > reflects to reflects the pull requests that are currently in
>     > master
>     > > > > > Construct an email to the Metron dev board (
>     > > > > dev@metron.incubator.apache.org) which discusses with the
>     > community
>     > > the
>     > > > > desire to do a release. This email should contain the following:
>     > > > > > The list of JIRAs slated for the release with descriptions
>     > (use
>     > > the
>     > > > > output of git log and remove all the JIRAs from the last
>     > release’s
>     > > > > changelog)
>     > > > > > A solicitation of JIRAs that should be included with the
>     > next
>     > > > > release. Users should rate them as must/need/good to have as
>     > well as
>     > > > > volunteering.
>     > > > > > A release email template is provided here.
>     > > > > > Step 2 - Monitor and Verify JIRAs
>     > > > > > Once the community votes for additional JIRAs they want
>     > included
>     > > in
>     > > > > the release verify that the pull requests are in before the
>     > release,
>     > > > close
>     > > > > these JIRAs and tag them with the release name. All pull
>     > requests and
>     > > > JIRAs
>     > > > > that were not slated for this release will go into the next
>     > releases.
>     > > The
>     > > > > release manager should continue to monitor the JIRA to ensure
>     > that the
>     > > > > timetable is on track until the release date. On the release
>     > date the
>     > > > > release manager should message the Metron dev board (
>     > > > > dev@metron.incubator.apache.org) announcing the code freeze for
>     > the
>     > > > > release.
>     > > > > > Step 3 - Create the Release Branch and Increment Metron
>     > version
>     > > > > > Create an branch for the release (from a repo cloned from
>     > > > > https://git-wip-us.apache.org/repos/asf/incubator-metron.git).
>     > > (assuming
>     > > > > the release is 0.[FR++].0 and working from master):
>     > > > > > git checkout -b Metron_0.[FR++].0
>     > > > > > git push --set-upstream origin Metron_0.[FR++].0
>     > > > > > File a JIRA to increment the Metron version to 0.[FR++].0.
>     > Either
>     > > > do
>     > > > > it yourself or have a community member increment the build
>     > version for
>     > > > you.
>     > > > > You can look at a pull request for a previous build to see how
>     > this is
>     > > > > done. METRON-533 - Up the version for release DONE
>     > > > > > Also, the release manager should have a couple of things
>     > set up:
>     > > > > > A SVN clone of the repo at https://dist.apache.org/repos/
>     > > > > dist/dev/incubator/metron, We will refer to this as the dev
>     > repo. It
>     > > will
>     > > > > hold the release candidate artifacts
>     > > > > > A SVN clone of the repo at https://dist.apache.org/repos/
>     > > > > dist/release/incubator/metron, We will refer to this as the
>     > release
>     > > repo.
>     > > > > It will hold the release artifacts.
>     > > > > > Step 4 - Create the Release Candidate
>     > > > > >
>     > > > > > Now, for each release candidate, we will tag from that
>     > branch.
>     > > > > Assuming that this is RC1:
>     > > > > > git checkout Metron_0.[FR++].0 && git pull
>     > > > > > git tag apache-metron-0.[FR++].0-rc1-incubating
>     > > > > > git push origin —tags
>     > > > > >
>     > > > > > Now, we must grab the release candidate binary from the
>     > github
>     > > > > releases page (https://github.com/apache/
>     > incubator-metron/releases).
>     > > In
>     > > > > our case, for RC1, that would be https://github.com/apache/
>     > > > > incubator-metron/archive/apache-metron-0.[FR++].0-rc1-
>     > > incubating.tar.gz
>     > > > > We will refer to this as the release candidate tarball.
>     > > > > > The artifacts for a release (or a release candidate, for
>     > that
>     > > > > matter) are as follows:
>     > > > > > Release (candidate) Tarball
>     > > > > > MD5 hash of the release tarball (md5 apache-metron-Now,
>     > we must
>     > > > > grab the release candidate binary from the github releases page (
>     > > > > https://github.com/apache/incubator-metron/releases). In our
>     > case, for
>     > > > > RC1, that would be https://github.com/apache/
>     > incubator-metron/archive/
>     > > > > apache-metron-0.[FR++].0-rc1-incubating.tar.gz We will refer to
>     > this
>     > > as
>     > > > > the release candidate tarball.-rc1-incubating.tar.gz >
>     > > > > apache-metron-0.[FR++].0-rc1-incubating.tar.gz.md5)
>     > > > > > SHA1 hash of the release tarball (gpg --print-md SHA1
>     > > > > apache-metron-0.[FR++].0-rc1-incubating.tar.gz >
>     > > > > apache-metron-0.[FR++].0-rc1-incubating.tar.gz.sha)
>     > > > > > GPG signature of release tarball by the release manager
>     > > > > > Assuming your public code signing key is 0xDEADBEEF, so
>     > signing
>     > > > for
>     > > > > me would be: gpg -u 0xDEADBEEF --armor --output
>     > > > > apache-metron-0.[FR++].0-rc1-incubating.tar.gz.asc --detach-sig
>     > > > > apache-metron-0.[FR++].0-rc1-incubating.tar.gz
>     > > > > > If you do not know your code signing key as release
>     > manager, you
>     > > > > must follow the instructions at https://www.apache.org/dev/
>     > > > > release-signing.html#generate
>     > > > > > Note: You only need the -u arg if you have more than one
>     > > > > public/private key pair generated. If you have forgotten it, you
>     > can
>     > > find
>     > > > > it from the output of gpg —fingerprint. It’s the last 4 bytes
>     > from the
>     > > > key
>     > > > > fingerprint.
>     > > > > > The LICENSE file from the release tarball
>     > > > > > The KEYS file from the release tarball
>     > > > > > The DISCLAIMER file from the release tarball
>     > > > > > A CHANGES file denoting the changes
>     > > > > > We usually construct this by taking the output of git log
>     > | grep
>     > > > > METRON | sed 's/\[//g' | sed 's/\]//g' | grep -v “http” and
>     > removing
>     > > the
>     > > > > JIRAs from the previous releases (it’s in time sorted order so
>     > this is
>     > > > > easy).
>     > > > > >
>     > > > > > Create a directory named ${VERSION}-RC${RC_NUM}-incubating
>     > (in
>     > > our
>     > > > > case, it’s 0.[FR++].0-RC1-incubating) in the dev repo. Place the
>     > > > artifacts
>     > > > > from above into this directory, add the directory and commit via
>     > the
>     > > > > subversion client:
>     > > > > > svn add 0.[FR++].0-RC1-incubating
>     > > > > > svn commit -m "Adding artifacts for Metron 0.[FR++].0-RC1
>     > > > > (incubating)”
>     > > > > > Step 5 - Verify the build
>     > > > > > Go through the build verification checklist to verify that
>     > > > > everything works. These instructions can be found here: Verifying
>     > > Builds
>     > > > > > Step 6 - Verify licensing
>     > > > > > Make sure the release compiles with the following Apache
>     > > licensing
>     > > > > guidelines: http://www.apache.org/foundation/license-faq.html
>     > > > > > Step 7 - Call for a community release vote
>     > > > > > Next initiate a [VOTE] threat on the dev list to announce
>     > the
>     > > build
>     > > > > vote. The vote email template can be found here: Build Vote
>     > Template.
>     > > > Allow
>     > > > > at least 72 hours for the community to vote on the release. When
>     > you
>     > > get
>     > > > > enough votes close the vote by replying [RESULT][VOTE] to the
>     > email
>     > > > thread
>     > > > > with the tally of all the votes
>     > > > > > Step 8 - Call for a incubator release vote
>     > > > > > Once the community has successfully voted on a release, we
>     > must
>     > > > > escalate the vote to the incubator general. The same VOTE thread
>     > > original
>     > > > > email is sent to gene...@incubator.apache.org
>     > > > > >
>     > > > > > If issues are found with the release and the vote fails,
>     > then the
>     > > > > vote thread is closed with a synopsis of the voting results and
>     > a new
>     > > RC
>     > > > is
>     > > > > worked on in the community
>     > > > > > If issues are found with the release and the vote
>     > succeeds, then
>     > > we
>     > > > > proceed to cut the release, but should notify the community of
>     > the
>     > > issues
>     > > > > via an email on the dev list with the accompanying JIRA(s)
>     > required to
>     > > > > correct the issue(s).
>     > > > > >
>     > > > > > If no issues are found, then we can cut a release
>     > > > > > Again, wait for at least 72 hours and then close the vote.
>     > > > > > Step 9 - Stage the finished release
>     > > > > > A directory with the name of the version (i.e. 0.3.0)
>     > should be
>     > > > made
>     > > > > in the release svn repository
>     > > > > >
>     > > > > > Collateral from the release candidate in the dev repo
>     > should be
>     > > > > moved to the above directory and renamed to remove the rc (e.g.
>     > mv
>     > > > > apache-metron-0.3.0-rc1-incubating.tar.gz.sha
>     > apache-metron-0.3.0-
>     > > > > incubating.tar.gz.sha)
>     > > > > >
>     > > > > > Add the directory and commit via the subversion client:
>     > > > > >
>     > > > > > svn add 0.3.0-RC1-incubating
>     > > > > > svn commit -m "Adding artifacts for Metron 0.3.0
>     > (incubating)”
>     > > > > >
>     > > > > > Remove the old releases from the release repo (only the
>     > current
>     > > > > version and the KEYS file should exist there).
>     > > > > > Step 14 - Announce build
>     > > > > > Send an email out to user@ and dev@ to announce the
>     > release
>     > > along
>     > > > > with the changelog and a word of thanks/praise.
>     > > > > > Creating a Maintenance Release
>     > > > > > Creation of the Maintenance Release should follow exactly
>     > the
>     > > same
>     > > > > set of steps as creating the Feature Release as outlined above,
>     > but
>     > > with
>     > > > > two exception. First, the version incremented on the maintenance
>     > > release
>     > > > > should be the MR++ so that the release is named 0.[FR].[MR++].
>     > Second,
>     > > > if a
>     > > > > critical JIRA comes in that requires an immediate patch we may
>     > forego
>     > > > steps
>     > > > > 2-5 and immediately cut the MR release. A critical JIRA is
>     > something
>     > > that
>     > > > > is either a security vulnerability or a functional show stopper .
>     > > > > > Ensuring Consistency between Feature and Maintenance
>     > releases
>     > > > > > Being able to maintain the previous release train, with
>     > only
>     > > > > critical or important bug fixes and security fixes (generally
>     > not new
>     > > > > features) for users who are averse to frequent large changes is
>     > very
>     > > > > important for production use. They get stability, while the
>     > feature
>     > > code
>     > > > > proceeds as fast as the community wishes. It is important to
>     > assure
>     > > that
>     > > > > all commits to the maintenance release also get made in the
>     > feature
>     > > > branch
>     > > > > (if relevant), to avoid the appearance of regressions in the
>     > > maintenance
>     > > > > branch. The formal process for assuring this is as follows:
>     > > > > > Every maintenance release JIRA should have a corresponding
>     > > feature
>     > > > > JIRA to make sure that the patch is applied consistently to both
>     > > > branches.
>     > > > > The maintenance JIRA should be cloned and appropriate fix
>     > version for
>     > > the
>     > > > > feature release should be applied. If the fix is not relevant to
>     > the
>     > > > > feature or maintenance branch then the submitter must explicitly
>     > state
>     > > > > this. In general reviewers should refuse a patch PR unless both
>     > feature
>     > > > and
>     > > > > maintenance JIRAs have been created.
>     > > > > > The release manager has a responsibility to review all
>     > commits to
>     > > > > the maintenance line since last release, and make sure they were
>     > > > duplicated
>     > > > > to the feature branch (unless not relevant, which must also be
>     > > > determined).
>     > > > > >
>     > > > > > 05.01.2017, 06:32, "larry mccay" <lmc...@apache.org>:
>     > > > > >> Hi James -
>     > > > > >>
>     > > > > >> This looks pretty good!
>     > > > > >>
>     > > > > >> A couple quick comments:
>     > > > > >>
>     > > > > >> * for step 10 - the KEYS file appears to be provided for
>     > each
>     > > > > release as
>     > > > > >> part of the release candidate itself. While I do see some
>     > > > projects
>     > > > > do this,
>     > > > > >> I think it is actually best practice to have a single
>     > KEYS file
>     > > > in
>     > > > > a well
>     > > > > >> known place outside of the rc. This decoupling is
>     > supposed to
>     > > > make
>     > > > > it more
>     > > > > >> difficult for an artifact to be tampered with and
>     > another KEYS
>     > > > file
>     > > > > >> provided. I think most projects that keep the KEYS
>     > separate
>     > > just
>     > > > > put them at
>     > > > > >> the top level of the ASF mirror area for the project
>     > such as at
>     > > > > >> https://dist.apache.org/repos/dist/*release*/incubator/
>     > metron/
>     > > > > [1].
>     > > > > >> * Related to the above, it seems that in the KEYS file is
>     > > > > duplicated at the
>     > > > > >> top level of the ASF mirror area for the project as well
>     > as in
>     > > > the
>     > > > > release
>     > > > > >> directory. The one inside the release directory would
>     > probably
>     > > go
>     > > > > away by
>     > > > > >> addressing the previous comment but it should be noted
>     > that
>     > > there
>     > > > > is a
>     > > > > >> chance for those two files to be out of sync otherwise.
>     > > > > >> * I notice that the DISCLAIMER, LICENSE and CHANGES
>     > files are
>     > > > kept
>     > > > > outside
>     > > > > >> of the archives along with the KEYS file. As long as
>     > they are
>     > > > also
>     > > > > inside
>     > > > > >> the archive it is probably fine but I don't think there
>     > is a
>     > > need
>     > > > > for
>     > > > > >> LICENSE and DISCLAIMER to be outside. In Knox we do keep
>     > the
>     > > > > CHANGES
>     > > > > >> outside as well so that it can be easily reviewed to
>     > determine
>     > > > > interest or
>     > > > > >> need for upgrade etc.
>     > > > > >> * I do also notice that there is no zip archive - you
>     > may want
>     > > to
>     > > > > consider
>     > > > > >> adding a zip as well.
>     > > > > >> * steps 10 and 13 instruct the release manager to stage
>     > the rc
>     > > > and
>     > > > > the
>     > > > > >> final release but there aren't any instructions as to
>     > how to do
>     > > > > so. Is that
>     > > > > >> documented elsewhere? We have specific ant targets to
>     > run for
>     > > > > >> stage-candidate and promote-release [2].
>     > > > > >>
>     > > > > >> Hope this is helpful.
>     > > > > >>
>     > > > > >> 1. https://www.apache.org/dev/release-signing.html#keys-
>     > policy
>     > > > > >> 2.
>     > > > > >> https://cwiki.apache.org/confluence/display/KNOX/
>     > > > Release+Process#
>     > > > > ReleaseProcess-Stage
>     > > > > >>
>     > > > > >> thanks,
>     > > > > >>
>     > > > > >> --larry
>     > > > > >>
>     > > > > >> On Wed, Jan 4, 2017 at 7:25 PM, Matt Foley <
>     > ma...@apache.org>
>     > > > > wrote:
>     > > > > >>
>     > > > > >>> Hi James, is there a formatted version of this
>     > somewhere we
>     > > can
>     > > > > look at?
>     > > > > >>> Thanks,
>     > > > > >>> --Matt
>     > > > > >>>
>     > > > > >>> On 1/4/17, 1:53 PM, "James Sirota" <jsir...@apache.org
>     > >
>     > > wrote:
>     > > > > >>>
>     > > > > >>> Revised as per additional comments. Are there more
>     > > > comments?
>     > > > > Or can
>     > > > > >>> we put this up for a vote?
>     > > > > >>>
>     > > > > >>> Release Process [DRAFT]
>     > > > > >>> Skip to end of metadata
>     > > > > >>> Created by James Sirota, last modified just a
>     > moment ago
>     > > Go
>     > > > > to start
>     > > > > >>> of metadata
>     > > > > >>> Metron Release Types
>     > > > > >>> There are two types of Metron releases:
>     > > > > >>> Feature Release (FR) - this is a release that has a
>     > > > > significant step
>     > > > > >>> forward in feature capability and is denoted by an
>     > upgrade of
>     > > > > the second
>     > > > > >>> digit
>     > > > > >>> Maintenance Release (MR) - this is a set of
>     > patches and
>     > > > > fixes that are
>     > > > > >>> issued following the FR and is denoted by an upgrade
>     > of the
>     > > > > third digit
>     > > > > >>> Release Naming Convention
>     > > > > >>> Metron build naming convention is as follows:
>     > > 0.[FR].[MR].
>     > > > > We keep
>     > > > > >>> the 0. notation to signify that the project is still
>     > under
>     > > > active
>     > > > > >>> development and we will hold a community vote to go to
>     > 1.x
>     > > at a
>     > > > > future time
>     > > > > >>> Initiating a New Metron Release
>     > > > > >>> Immediately upon the release of the previous Metron
>     > > release
>     > > > > create two
>     > > > > >>> branches: FR ++ and MR. Create the FR++ branch by
>     > > incrementing
>     > > > > the second
>     > > > > >>> digit like so 0.[FR++].0. Create the MR branch for the
>     > > previous
>     > > > > Metron
>     > > > > >>> release by incrementing the second digit of the
>     > previous
>     > > > release
>     > > > > like so
>     > > > > >>> 0.[FR].[MR]. All patches to the previous Metron
>     > release will
>     > > be
>     > > > > checked in
>     > > > > >>> under the MR branch and where it makes sense also
>     > under the
>     > > FR
>     > > > > branch. All
>     > > > > >>> new features will be checked in under the FR branch.
>     > > > > >>> Creating a Feature Release
>     > > > > >>> Step 1 - Initiate a discuss thread
>     > > > > >>> A week before a new feature release initiate a
>     > discuss
>     > > > > thread on the
>     > > > > >>> Metron dev board announcing the upcoming release and
>     > asking
>     > > the
>     > > > > community
>     > > > > >>> which still outstanding pull requests people want to
>     > include
>     > > in
>     > > > > the next
>     > > > > >>> build.
>     > > > > >>> Step 2 - Verify JIRA
>     > > > > >>> Go through the JIRA and verify that all pull
>     > requests
>     > > that
>     > > > > were merged
>     > > > > >>> for the upcoming build have JIRAs that are in a closed
>     > state
>     > > > and
>     > > > > are
>     > > > > >>> appropriately labelled with the next build version.
>     > > > > >>> Step 3 - Announce a code freeze
>     > > > > >>> A day before the release date comment on the
>     > discuss
>     > > thread
>     > > > > and let
>     > > > > >>> people know that the release is ready. Go through the
>     > JIRAs
>     > > for
>     > > > > pull
>     > > > > >>> requests that came in during the last week and make
>     > sure they
>     > > > > are labelled
>     > > > > >>> with the next build version.
>     > > > > >>> Step 4 - Increment Metron version
>     > > > > >>> File a JIRA to increment the Metron version to
>     > > 0.[FR++].0.
>     > > > > Either do
>     > > > > >>> it yourself or have a community member increment the
>     > build
>     > > > > version for
>     > > > > >>> you. You can look at a pull request for a previous
>     > build to
>     > > see
>     > > > > how this
>     > > > > >>> is done
>     > > > > >>> Step 5 - Increment build version
>     > > > > >>> File a JIRA to increment the Metron version to
>     > > > > 0.[FR++].0-RC(n), where
>     > > > > >>> RC(n) is the number of the release candidate. Sometimes
>     > > > mistakes
>     > > > > occur
>     > > > > >>> (builds may get voted down) so it will take multiple
>     > RCs to
>     > > get
>     > > > > a build
>     > > > > >>> through the vote. The RC(n) will be removed after the
>     > > > successful
>     > > > > vote.
>     > > > > >>> Step 6 - Verify the build
>     > > > > >>> Go through the build verification checklist to
>     > verify
>     > > that
>     > > > > everything
>     > > > > >>> works. These instructions can be found here: Verifying
>     > Builds
>     > > > > >>> Step 7 - Verify licensing
>     > > > > >>> Make sure the release compiles with the following
>     > Apache
>     > > > > licensing
>     > > > > >>> guidelines: http://www.apache.org/
>     > > foundation/license-faq.html
>     > > > > >>> Step 8 - Generate the changes file
>     > > > > >>> Go through the JIRA to generate the changes file,
>     > which
>     > > > > contains a
>     > > > > >>> list of all JIRAs included in the upcoming release. An
>     > > example
>     > > > > of a
>     > > > > >>> changes file can be found here:
>     > > https://dist.apache.org/repos/
>     > > > > >>> dist/dev/incubator/metron/0.3.0-RC1-incubating/CHANGES
>     > > > > >>> Step 9 - Tag the RC release
>     > > > > >>> Tag the release for the RC in case we need to roll
>     > back
>     > > at
>     > > > > some
>     > > > > >>> point. An example of a valid tag can be seen here:
>     > > > > >>> https://git-wip-us.apache.org/
>     > > repos/asf?p=incubator-metron
>     > > > .
>     > > > > >>> git;a=shortlog;h=refs/tags/apache-metron-0.3.0-rc1-
>     > > incubating
>     > > > > >>> Step 10 - Stage the release
>     > > > > >>> The next thing to do is to sign and stage the
>     > release
>     > > > > including the
>     > > > > >>> DISCLAIMER, KEYS, and LICENSE files. A properly signed
>     > and
>     > > > > staged release
>     > > > > >>> can be found here:
>     > > > > >>> https://dist.apache.org/repos/
>     > > > dist/dev/incubator/metron/0.3.
>     > > > > >>> 0-RC1-incubating/
>     > > > > >>> * Make sure you have your correct profile and keys
>     > > uploaded
>     > > > > to
>     > > > > >>> https://id.apache.org/ to properly sign the release
>     > and to
>     > > get
>     > > > > access to
>     > > > > >>> dist.apache.org
>     > > > > >>> Step 11 - Call for a community release vote
>     > > > > >>> Next initiate a [VOTE] threat on the dev list to
>     > announce
>     > > > > the build
>     > > > > >>> vote. The vote email template can be found here: Build
>     > Vote
>     > > > > Template.
>     > > > > >>> Allow at least 72 hours for the community to vote on
>     > the
>     > > > > release. When you
>     > > > > >>> get enough votes close the vote by replying
>     > [RESULT][VOTE] to
>     > > > > the email
>     > > > > >>> thread with the tally of all the votes
>     > > > > >>> Step 12 - Call for a incubator release vote
>     > > > > >>> Upon successful completion of step 11, repeat, but
>     > now
>     > > send
>     > > > > the email
>     > > > > >>> to the incubator general boards. The email should be
>     > > identical.
>     > > > > Again,
>     > > > > >>> wait for at least 72 hours and then close the vote.
>     > > > > >>> Step 13 - Stage the finished release
>     > > > > >>> If the vote fails at any stage then incorporate
>     > feedback,
>     > > > > create
>     > > > > >>> another RC, and repeat. If both votes pass then stage
>     > the
>     > > > > resulting
>     > > > > >>> artifacts here: https://dist.apache.org/repos/
>     > > > > >>> dist/release/incubator/metron/
>     > > > > >>> Step 14 - Announce build
>     > > > > >>> Send a discuss thread to the Metron dev boards
>     > announcing
>     > > > > the new
>     > > > > >>> Metron build
>     > > > > >>> Creating a Maintenance Release
>     > > > > >>> Creation of the Maintenance Release should follow
>     > exactly
>     > > > > the same set
>     > > > > >>> of steps as creating the Feature Release as outlined
>     > above,
>     > > but
>     > > > > with two
>     > > > > >>> exception. First, the version incremented on the
>     > maintenance
>     > > > > release
>     > > > > >>> should be the MR++ so that the release is named
>     > > 0.[FR].[MR++].
>     > > > > Second, if
>     > > > > >>> a critical JIRA comes in that requires an immediate
>     > patch we
>     > > > may
>     > > > > forego
>     > > > > >>> steps 2-5 and immediately cut the MR release. A
>     > critical JIRA
>     > > > is
>     > > > > something
>     > > > > >>> that is either a security vulnerability or a
>     > functional show
>     > > > > stopper .
>     > > > > >>> Ensuring Consistency between Feature and
>     > Maintenance
>     > > > releases
>     > > > > >>> Being able to maintain the previous release train,
>     > with
>     > > > only
>     > > > > critical
>     > > > > >>> or important bug fixes and security fixes (generally
>     > not new
>     > > > > features) for
>     > > > > >>> users who are averse to frequent large changes is very
>     > > > important
>     > > > > for
>     > > > > >>> production use. They get stability, while the feature
>     > code
>     > > > > proceeds as
>     > > > > >>> fast as the community wishes. It is important to
>     > assure that
>     > > > all
>     > > > > commits
>     > > > > >>> to the maintenance release also get made in the feature
>     > > branch
>     > > > > (if
>     > > > > >>> relevant), to avoid the appearance of regressions in
>     > the
>     > > > > maintenance
>     > > > > >>> branch. The formal process for assuring this is as
>     > follows:
>     > > > > >>> Every maintenance release JIRA should have a
>     > > corresponding
>     > > > > feature
>     > > > > >>> JIRA to make sure that the patch is applied
>     > consistently to
>     > > > both
>     > > > > branches.
>     > > > > >>> The maintenance JIRA should be cloned and appropriate
>     > fix
>     > > > > version for the
>     > > > > >>> feature release should be applied. If the fix is not
>     > relevant
>     > > > to
>     > > > > the
>     > > > > >>> feature or maintenance branch then the submitter must
>     > > > explicitly
>     > > > > state
>     > > > > >>> this. In general reviewers should refuse a patch PR
>     > unless
>     > > both
>     > > > > feature
>     > > > > >>> and maintenance JIRAs have been created.
>     > > > > >>> The release manager has a responsibility to review
>     > all
>     > > > > commits to the
>     > > > > >>> maintenance line since last release, and make sure
>     > they were
>     > > > > duplicated to
>     > > > > >>> the feature branch (unless not relevant, which must
>     > also be
>     > > > > determined).
>     > > > > >>>
>     > > > > >>> 20.12.2016, 11:45, "Matt Foley" <ma...@apache.org
>     > >:
>     > > > > >>> > 1. Agree. Being able to maintain the previous
>     > release
>     > > > > train, with
>     > > > > >>> only critical or important bug fixes and security fixes
>     > > > > (generally not new
>     > > > > >>> features) for users who are averse to frequent large
>     > changes,
>     > > > is
>     > > > > very
>     > > > > >>> important for production use. They get stability,
>     > while the
>     > > > > mainline code
>     > > > > >>> proceeds as fast as the community wishes.
>     > > > > >>> > a. As Kyle points out, it is important to assure
>     > that
>     > > all
>     > > > > commits to
>     > > > > >>> the maintenance line also get made in the mainline (if
>     > > > > relevant), to avoid
>     > > > > >>> the appearance of regressions in the mainline. There
>     > should
>     > > be
>     > > > a
>     > > > > formal
>     > > > > >>> process for assuring this. Possibilities are:
>     > > > > >>> > i. The release manager has a responsibility to
>     > review
>     > > all
>     > > > > commits to
>     > > > > >>> the maint line since last release, and make sure they
>     > were
>     > > > > duplicated to
>     > > > > >>> the mainline (unless not relevant, which must also be
>     > > > > determined).
>     > > > > >>> > ii. Reviewers refuse to accept PRs for the maint
>     > line
>     > > > > unless they
>     > > > > >>> are twinned with PRs for corresponding changes in the
>     > > mainline
>     > > > > (unless not
>     > > > > >>> relevant, which must be stated by the submitter). This
>     > should
>     > > > be
>     > > > > reflected
>     > > > > >>> in Jira practices as well as PR practices. Note Jira
>     > is poor
>     > > at
>     > > > > tracking
>     > > > > >>> multiple “Fix Version/s” values (due to the ambiguous
>     > use of
>     > > > > “Fix version”
>     > > > > >>> to mean both “target version” and “done version”).
>     > Most teams
>     > > > > just clone
>     > > > > >>> jira tickets for multiple target releases.
>     > > > > >>> > 2. Agree. Being a release manager is a
>     > significant
>     > > > > commitment of
>     > > > > >>> both time and care, and should be rotated around; both
>     > for
>     > > the
>     > > > > benefit of
>     > > > > >>> the individuals involved and so that at least 2 or 3
>     > people
>     > > are
>     > > > > deeply
>     > > > > >>> familiar with the process at any given time.
>     > > > > >>> > --Matt
>     > > > > >>> >
>     > > > > >>> > On 12/20/16, 8:15 AM, "James Sirota" <
>     > > jsir...@apache.org
>     > > > >
>     > > > > wrote:
>     > > > > >>> >
>     > > > > >>> > You are correct. This thread is about the release
>     > > > process:
>     > > > > >>> > https://cwiki.apache.org/
>     > confluence/pages/viewpage.
>     > > > > >>> action?pageId=66854770
>     > > > > >>> >
>     > > > > >>> > Does anyone have additional opinions on this?
>     > > > > >>> >
>     > > > > >>> > 1. Maintenance release would just contain
>     > patches to
>     > > the
>     > > > > >>> existing release. Feature release would contain
>     > everything,
>     > > > > including
>     > > > > >>> patches and new features.
>     > > > > >>> > 2. The intention is to rotate the build manager.
>     > I did
>     > > it
>     > > > > for
>     > > > > >>> the first few releases, then Casey did it for the next
>     > few
>     > > > > releasees,
>     > > > > >>> someone else will probably do it for the next few
>     > releases,
>     > > > > etc...
>     > > > > >>> >
>     > > > > >>> > Does this seem reasonable to everyone?
>     > > > > >>> >
>     > > > > >>> > Thanks,
>     > > > > >>> > James
>     > > > > >>> >
>     > > > > >>> > 18.12.2016, 18:15, "Kyle Richardson" <
>     > > > > kylerichards...@gmail.com
>     > > > > >>> >:
>     > > > > >>> > > I think this thread got commingled with the
>     > > discussion
>     > > > on
>     > > > > >>> Coding
>     > > > > >>> > > Guidelines. The wiki page on the Release
>     > Process is
>     > > at
>     > > > > >>> > > https://cwiki.apache.org/
>     > confluence/pages/viewpage.
>     > > > > >>> action?pageId=66854770.
>     > > > > >>> > >
>     > > > > >>> > > Overall, a really informative document. Thanks
>     > for
>     > > > > pulling
>     > > > > >>> this together.
>     > > > > >>> > > Two questions:
>     > > > > >>> > >
>     > > > > >>> > > 1) I'm a little confused about how the feature
>     > > release
>     > > > > and
>     > > > > >>> maintenance
>     > > > > >>> > > release branches are going to work. Is the
>     > idea that
>     > > > all
>     > > > > PRs
>     > > > > >>> will be merged
>     > > > > >>> > > into master and then also be committed to a
>     > FR++ or a
>     > > > > MR++
>     > > > > >>> branch (or maybe
>     > > > > >>> > > even both)?
>     > > > > >>> > >
>     > > > > >>> > > 2) Are these steps to be taken by a release
>     > manager
>     > > > only
>     > > > > or is
>     > > > > >>> the
>     > > > > >>> > > intention that other committers or PMC members
>     > rotate
>     > > > > through
>     > > > > >>> this
>     > > > > >>> > > responsibly? Just curious. I actually kind of
>     > like
>     > > the
>     > > > > idea of
>     > > > > >>> shuffling
>     > > > > >>> > > the duty every now and then to avoid burnout
>     > by one
>     > > > > person.
>     > > > > >>> > >
>     > > > > >>> > > -Kyle
>     > > > > >>> > >
>     > > > > >>> > > On Fri, Dec 16, 2016 at 1:31 PM, James Sirota <
>     > > > > >>> jsir...@apache.org> wrote:
>     > > > > >>> > >
>     > > > > >>> > >> fixed the link and made one addition that a
>     > > qualified
>     > > > > >>> reviewer is a
>     > > > > >>> > >> committer or PPMC member
>     > > > > >>> > >>
>     > > > > >>> > >> 16.12.2016, 11:07, "zeo...@gmail.com" <
>     > > > zeo...@gmail.com
>     > > > > >:
>     > > > > >>> > >> > Right, I agree. That change looks good to
>     > me.
>     > > > > >>> > >> >
>     > > > > >>> > >> > Looks like the Log4j levels links is broken
>     > too.
>     > > > > >>> > >> >
>     > > > > >>> > >> > For a broken travis - how about "If somehow
>     > the
>     > > > tests
>     > > > > get
>     > > > > >>> into a failing
>     > > > > >>> > >> > state on master (such as by a backwards
>     > > incompatible
>     > > > > >>> release of a
>     > > > > >>> > >> > dependency) only pull requests intended to
>     > rectify
>     > > > > master
>     > > > > >>> may be merged,
>     > > > > >>> > >> > and the removal or disabling of any tests
>     > must be
>     > > > > +1'd by
>     > > > > >>> two reviewers."
>     > > > > >>> > >> >
>     > > > > >>> > >> > Also, reading through this, should there
>     > should
>     > > be a
>     > > > > >>> delineation between
>     > > > > >>> > >> a
>     > > > > >>> > >> > "reviewer" and somebody who has the ability
>     > to
>     > > > > vote/+1 a
>     > > > > >>> PR? Unless I'm
>     > > > > >>> > >> > missing something, right now it looks open
>     > to
>     > > > anybody.
>     > > > > >>> > >> >
>     > > > > >>> > >> > Jon
>     > > > > >>> > >> >
>     > > > > >>> > >> > On Fri, Dec 16, 2016 at 12:48 PM Nick Allen
>     > <
>     > > > > >>> n...@nickallen.org> wrote:
>     > > > > >>> > >> >
>     > > > > >>> > >> > Personally, I don't think it matters who
>     > merges
>     > > the
>     > > > > pull
>     > > > > >>> request. As long
>     > > > > >>> > >> > as you meet the requirements for code
>     > review, then
>     > > > > anyone
>     > > > > >>> should be able
>     > > > > >>> > >> to
>     > > > > >>> > >> > merge it. In fact, I'd rather have the
>     > person who
>     > > > > knows
>     > > > > >>> most about the
>     > > > > >>> > >> > change actually merge it into master to
>     > ensure
>     > > that
>     > > > > it goes
>     > > > > >>> smoothly.
>     > > > > >>> > >> >
>     > > > > >>> > >> > On Fri, Dec 16, 2016 at 12:15 PM, James
>     > Sirota <
>     > > > > >>> jsir...@apache.org>
>     > > > > >>> > >> wrote:
>     > > > > >>> > >> >
>     > > > > >>> > >> >> Jon, for #2 I changed it to: A committer
>     > may
>     > > merge
>     > > > > their
>     > > > > >>> own pull
>     > > > > >>> > >> request,
>     > > > > >>> > >> >> but only after a second reviewer has given
>     > it a
>     > > +1.
>     > > > > >>> > >> >>
>     > > > > >>> > >> >> 16.12.2016, 10:07, "zeo...@gmail.com" <
>     > > > > zeo...@gmail.com>:
>     > > > > >>> > >> >> > I made some minor changes to the doc -
>     > check
>     > > out
>     > > > > the
>     > > > > >>> history
>     > > > > >>> > >> >> > <https://cwiki.apache.org/
>     > confluence/pages/
>     > > > > >>> > >> viewpreviousversions.action?
>     > > > > >>> > >> >> pageId=61332235>
>     > > > > >>> > >> >> > if you have any concerns.
>     > > > > >>> > >> >> >
>     > > > > >>> > >> >> > Regarding the larger doc -
>     > > > > >>> > >> >> > 1. Not everybody can assign JIRAs to
>     > > themselves.
>     > > > I
>     > > > > >>> recall I had to
>     > > > > >>> > >> >> request
>     > > > > >>> > >> >> > this access, so that should probably be
>     > > > mentioned.
>     > > > > >>> > >> >> > 2. "A committer may never merge their
>     > own pull
>     > > > > request,
>     > > > > >>> a second
>     > > > > >>> > >> party
>     > > > > >>> > >> >> must
>     > > > > >>> > >> >> > merge their changes after it has be
>     > properly
>     > > > > reviewed."
>     > > > > >>> > >> >> > - Is this still true/accurate? I heard
>     > both
>     > > ways.
>     > > > > >>> > >> >> > 3. "If somehow the tests get into a
>     > failing
>     > > state
>     > > > > on
>     > > > > >>> master (such as
>     > > > > >>> > >> by
>     > > > > >>> > >> >
>     > > > > >>> > >> > a
>     > > > > >>> > >> >> > backwards incompatible release of a
>     > dependency)
>     > > > no
>     > > > > pull
>     > > > > >>> requests may
>     > > > > >>> > >> be
>     > > > > >>> > >> >> > merged until this is rectified."
>     > > > > >>> > >> >> > - Maybe this should get reassessed using
>     > the
>     > > > > >>> > >> >> > <https://github.com/apache/
>     > > > > incubator-metron/pull/383>
>     > > > > >>> most
>     > > > > >>> > >> >> > <https://github.com/apache/
>     > > > > incubator-metron/pull/381>
>     > > > > >>> recent
>     > > > > >>> > >> >> > <https://issues.apache.org/
>     > > > jira/browse/METRON-601>
>     > > > > build
>     > > > > >>> > >> >> > <https://issues.apache.org/
>     > > > jira/browse/METRON-597>
>     > > > > >>> failures
>     > > > > >>> > >> >> > <https://github.com/apache/
>     > > > > incubator-metron/pull/380>
>     > > > > >>> as a valuable
>     > > > > >>> > >> case
>     > > > > >>> > >> >> > study.
>     > > > > >>> > >> >> >
>     > > > > >>> > >> >> > Jon
>     > > > > >>> > >> >> >
>     > > > > >>> > >> >> > On Fri, Dec 16, 2016 at 11:38 AM James
>     > Sirota <
>     > > > > >>> jsir...@apache.org>
>     > > > > >>> > >> >> wrote:
>     > > > > >>> > >> >> >
>     > > > > >>> > >> >> >> I threw together a draft document for
>     > our
>     > > > release
>     > > > > >>> process. Would you
>     > > > > >>> > >> >> want
>     > > > > >>> > >> >> >> to add/change/delete anything?
>     > > > > >>> > >> >> >>
>     > > > > >>> > >> >> >> -------------------
>     > > > > >>> > >> >> >> Thank you,
>     > > > > >>> > >> >> >>
>     > > > > >>> > >> >> >> James Sirota
>     > > > > >>> > >> >> >> PPMC- Apache Metron (Incubating)
>     > > > > >>> > >> >> >> jsirota AT apache DOT org
>     > > > > >>> > >> >> > --
>     > > > > >>> > >> >> >
>     > > > > >>> > >> >> > Jon
>     > > > > >>> > >> >> >
>     > > > > >>> > >> >> > Sent from my mobile device
>     > > > > >>> > >> >>
>     > > > > >>> > >> >> -------------------
>     > > > > >>> > >> >> Thank you,
>     > > > > >>> > >> >>
>     > > > > >>> > >> >> James Sirota
>     > > > > >>> > >> >> PPMC- Apache Metron (Incubating)
>     > > > > >>> > >> >> jsirota AT apache DOT org
>     > > > > >>> > >> >
>     > > > > >>> > >> > --
>     > > > > >>> > >> > Nick Allen <n...@nickallen.org>
>     > > > > >>> > >> >
>     > > > > >>> > >> > --
>     > > > > >>> > >> >
>     > > > > >>> > >> > Jon
>     > > > > >>> > >> >
>     > > > > >>> > >> > Sent from my mobile device
>     > > > > >>> > >>
>     > > > > >>> > >> -------------------
>     > > > > >>> > >> Thank you,
>     > > > > >>> > >>
>     > > > > >>> > >> James Sirota
>     > > > > >>> > >> PPMC- Apache Metron (Incubating)
>     > > > > >>> > >> jsirota AT apache DOT org
>     > > > > >>> >
>     > > > > >>> > -------------------
>     > > > > >>> > Thank you,
>     > > > > >>> >
>     > > > > >>> > James Sirota
>     > > > > >>> > PPMC- Apache Metron (Incubating)
>     > > > > >>> > jsirota AT apache DOT org
>     > > > > >>>
>     > > > > >>> -------------------
>     > > > > >>> Thank you,
>     > > > > >>>
>     > > > > >>> James Sirota
>     > > > > >>> PPMC- Apache Metron (Incubating)
>     > > > > >>> jsirota AT apache DOT org
>     > > > > >
>     > > > > > -------------------
>     > > > > > Thank you,
>     > > > > >
>     > > > > > James Sirota
>     > > > > > PPMC- Apache Metron (Incubating)
>     > > > > > jsirota AT apache DOT org
>     > > > >
>     > > > > -------------------
>     > > > > Thank you,
>     > > > >
>     > > > > James Sirota
>     > > > > PPMC- Apache Metron (Incubating)
>     > > > > jsirota AT apache DOT org
>     > > > >
>     > > > >
>     > > > >
>     > > > >
>     > > > >
>     > > >
>     > >
>     >
>     >
>     >
>     >
>     >

------------------- 
Thank you,

James Sirota
PPMC- Apache Metron (Incubating)
jsirota AT apache DOT org

Reply via email to