metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Leet <justinjl...@gmail.com>
Subject Re: [VOTE] Release Process Documentation
Date Tue, 24 Jan 2017 13:04:57 GMT
Another minor correction: the link at "*Note: Per Apache policy
<https://cwiki.apache.org/confluence/We%20will%20refer%20to%20this%20as%20the%20release%20candidate%20tarball.%20*Note:%20Per%20apache%20policy,%20the%20hardware%20used%20to%20create%20the%20candidate%20tarball%20must%20be%20owned%20by%20the%20release%20manager.>,
the hardware used to create the candidate tarball must be owned by the
release manager." is broken.

Justin

On Mon, Jan 23, 2017 at 12:38 PM, James Sirota <jsirota@apache.org> wrote:

> Sorry that's a typo. Was meant to be 10.  Just fixed
>
> 20.01.2017, 13:22, "Zeolla@GMail.com" <zeolla@gmail.com>:
> > -1 (non-binding).
> >
> > There appears to be a minor oversight where it goes from Step 9 to Step
> 14.
> >
> > Jon
> >
> > On Fri, Jan 20, 2017 at 11:56 AM James Sirota <jsirota@apache.org>
> wrote:
> >
> >>  The document is available here:
> >>  https://cwiki.apache.org/confluence/display/METRON/Release+Process
> >>
> >>  and is also pasted in this email for your convenience
> >>
> >>  Please vote +1, -1, or 0 for neutral. The vote will be open for 72
> hours
> >>
> >>  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
> >>  Create the MR branch for the previous Metron release by incrementing
> the
> >>  *third* 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 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. *Note: Per
> Apache
> >>  policy, the hardware used to create the candidate tarball must be
> owned by
> >>  the release manager.
> >>  The artifacts for a release (or a release candidate, for that matter)
> are
> >>  as follows:
> >>  Release (candidate) Tarball
> >>   MD5 hash of the release tarball. 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 complies 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] thread 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, the votes
> with
> >>  three binding +1's are still required, but Step 1 (discussion) and
> Step 2
> >>  (Jira collecting and tracking), and the 72 hour waiting periods in
> Steps 7
> >>  and 8 can be waived. A critical JIRA is something that is either a
> >>  security vulnerability or a functional show stopper.
> >>  Now, we must grab the release candidate binary from
> >>  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).
> >>
> >>  -------------------
> >>  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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message