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 Thu, 05 Jan 2017 00:25:54 GMT
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
    
    



Mime
View raw message