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 20:43:01 GMT
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