metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Foley <ma...@apache.org>
Subject Re: [VOTE] Release Process
Date Wed, 18 Jan 2017 20:03:00 GMT
+1 (non-binding)

BTW, here is a collection of small editorial changes.  Since these are editorial rather than
substantive, most project teams accept that they can be made by a responsible PMC member (such
as our esteemed chair :-) without re-voting or disrupting a vote in progress.  I suggest we
let James make these changes without changing the vote, altho of course if anyone who already
voted +1 feels that correcting these issues would invalidate your vote, please say so.

Step 4: 2nd bullet: Remove or change obsolete references to the github release tarball.

Step 6:  “compiles” --> “complies”

Step 7:  “threat” --> “thread”

Introduction, section “Initiating a New Metron Release”
This sentence is almost certainly a cut-and-paste error:
	“Create the MR branch for the previous Metron release by incrementing the second digit
of the previous release like so 0.[FR].[MR].”
I’m not entirely sure what it should read, but the most probable correction based on the
sentence before it would, I think, be (remove the asterisks):
	“Create the MR branch for the previous Metron release by incrementing the *third* digit
of the previous release like so 0.[FR].[*MR++*].”

At the end, section “Creating a Maintenance Release”
We got clarification on the urgent voting issue from Mentors, but steps 2-5 aren’t the steps
that get waived.  The two sentences:
	“Second, if a critical JIRA comes in that requires an immediate patch we may forego steps
2-5 and immediately cut the MR release.  By this we mean that 3 binding +1 votes are still
required, but the 72 hour waiting period can be waved.”
Should be changed to:
	“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.”

Cheers,
--Matt

On 1/17/17, 8:17 PM, "James Sirota" <jsirota@apache.org> wrote:

    I made the revisions based on the discuss thread
    
    The document is available here:
    https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=66854770
    
    And is also attached for reference to this email. 
    
    Please vote +1, -1, or 0 for neutral.  The vote will last 72 hours. 
    
    Thanks,
    James 
    
    -----------------
    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
    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 (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.  By this we mean that 3 binding +1 votes are still
required, but the 72 hour waiting period can be waved.  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
    
    




Mime
View raw message