metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Foley <ma...@apache.org>
Subject Re: [DISCUSS] Release Process
Date Tue, 17 Jan 2017 22:17:12 GMT
Sure, sounds fine to me.

On 1/17/17, 1:03 PM, "Casey Stella" <cestella@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 <mattf@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" <cestella@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 <lmccay@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 <cestella@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 <mattf@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" <jsirota@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" <jsirota@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 general@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" <lmccay@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 <
    > mattf@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" <jsirota@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" <mattf@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" <
    >     > jsirota@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" <
    >     > > > kylerichardson2@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 <
    >     > > >     >>>   jsirota@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, "Zeolla@GMail.com" <
    >     > > zeolla@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
    > <
    >     > > >     >>>   nick@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 <
    >     > > >     >>>   jsirota@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, "Zeolla@GMail.com" <
    >     > > > zeolla@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 <
    >     > > >     >>>   jsirota@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 <nick@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
    >     > > >
    >     > > >
    >     > > >
    >     > > >
    >     > > >
    >     > >
    >     >
    >
    >
    >
    >
    >
    



Mime
View raw message