Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Merged Release Manager and Lead responsibilities

Table of Contents
maxLevel5

 

Overview

The release manager lead role in Apache MXNet means you are responsible for a few different things:

...

  1. You are a current project committer
  2. You’ve gained access to configure build jobs at builds.apache.org as a part of the jobsadmin group (ask a PMC mentor to add you)

 

1. Preparing the Release Candidate:

...

After every release, the community should decide on a list of features to deliver for the following release. When the clear target date for a release has been estimated, the release manager lead should inform the community of the release schedule. All features which the community wishes to include in the release should be merged and tested successfully before the date of the first release candidate. The first release candidate should be on a commit which passed builds from at least 3 days before cutting the release candidate. This will make the release managerlead's job easier. Below is a template for the information:

...

  1. Bump up the version number. An example can be followed here: https://github.com/apache/incubator-mxnet/pull/6462, update https://github.com/apache/incubator-mxnet/blob/master/setup-utils/install-mxnet-osx-python.sh#L36
    More recent example - https://github.com/apache/incubator-mxnet/pull/8567
    make sure no broken/non-existing links are added to the master branch.
  2. Update NEWS and README. An example can be followed here: https://github.com/apache/incubator-mxnet/pull/6471
  3. Create a RSA GPG key of length 4096, upload it to the public server, and add it to the KEYS file (do this process once for each release managerlead): https://github.com/apache/incubator-mxnet/blob/master/KEYS & https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS See more detailed instructions on creating the key here: https://www.apache.org/dev/openpgp.html#generate-key

    Code Block
    languagebash
    titleAdding Keys
    # checkout the apache mxnet repo
    svn co https://dist.apache.org/repos/dist/dev/incubator/mxnet apache-mxnet
    cd apache-mxnet
    # update the KEYS file ...
    # commit the update
    svn commit -m “update keys file for xxx ” --username your_username --password your_passwd

...

Should any vote fail to reach quorum or release manager lead determines that another RC needs to go out, the release manager lead should triage the issues, create GitHub issues, and move to fix the issues. Once fixed, make changes to NEWS & README.md in case it specifically lists the old RC# number. Start the process for another release candidate. In the new voting email, detail what has changed since the last release candidate. Repeat until the vote passes.

...

Task #TaskOwnerRelative DateAbsolute Date
 PreReqs for Release Start:PM  
1Finalize the Release DatePMT-15 
2High Level List of Features and artifact specsPMT-15 
3Prepare Release Notes - draft 1PMT-15 
4Inform the communityRelease CommitterReleaseLeadT-15 
5PR to update the Website into master/RBWebsiteLeadT-14 
6PR to update the Docs into master/RBDocsLeadT-14 
7PR to update the versions into master/RBReleaseLeadT-14 
8Validate Licenses (how? Apache RAT and?)ReleaseLeadT-14 
9Validate/update submodulesReleaseLeadT-14 
10Stabilize the code for CI to passReleaseLeadT-14 
11Merge all necessary PRs into masterCommunityT-13 
     
12Code Freeze and Release Start: Cut the Release BranchRelease ManagerReleaseLeadT-10 
13Finalize the Release Notes based on PRs that got in - final draftPMT-10 
14PR to update the NEWS and README into the RBReleaseLeadT-9 
15validate the docs build locally (how?)DocsLeadT-9 
16Test part 1: Run the unit Tests on the Release BranchReleaseLeadT-8 
17Test part 2: Run the Nightly TestsReleaseLeadT-8 
18Create the Github Tag for the rc0Release CommitterReleaseLeadT-7 
19Create the src tar and sign, Upload the src tarRelease CommitterReleaseLeadT-7 
20Validate the signaturesRelease LeadT-7 
21Clone svn repo and do a manual testRelease LeadT-7 
     
 Begin Apache VotingRelease CommitterReleaseLeadT-7 
22Start the vote on devl@dev@ ReleaseLead  
23Send out the results of the vote on dev@Release CommitterReleaseLeadT-4 
24Revote if necessary (Steps 15-22)Release CommitterReleaseLeadNot Accounted For 
25Start the vote on general@Release CommitterReleaseLeadT-4 
26Send out the results of the vote on general@Release CommitterReleaseLeadT-1 
 End Apache Voting   
     
27Create the final release tag on githubRelease CommitterReleaseLeadT-1 
28Rename, resign and upload the src tar to final dirRelease CommitterReleaseLeadT-1 
29Update the website using tagWebsite LeadT-1 
30Release the official pip packagepip LeadT-1 
31Release the official docker imagesDocker LeadT-1 
32After 24 hrs, validate the packages are uploadedRelease LeadT 
33Draft the offical announce email and reviewRelease CommitterLeadT-1 
34Send out the email on announce@Release CommitterLeadT 
35Update the apache blogRelease CommitterLeadT 
36update the aws blogPMT 
37send internal announcementPMT 
38Update the version on masterRelease LeadT+1 

Notes for reference

*NOTES FROM DOCS FOR REFERENCE:*
http://incubator.apache.org/guides/releasemanagement.html

   - 3 +1 votes from IPMC members (these are the votes that count but we
   should open up to the whole podling community)
   - For podlings, 2 additional constraints:
   - Release artifacts must include “incubating” in final file name (ex:
      apache-mxnet-src-0.10.1-incubating.tar.gz)
   - Release artifacts must include disclaimer in the release artifacts


   - The Incubator PMC expects the source releases to be staged on
   https://dist.apache.org/repos/dist/dev/incubator/podlingName so that
   they can easily be moved to the release location via svn mv   (
   http://www.apache.org/dist/incubator/)
   - After graduating, RC’s go into https://dist.apache.org/repos/dist/dev/
   and official releases go into https://dist.apache.org/repos/dist/release/


http://incubator.apache.org/guides/branding.html#disclaimers

   - Apache Press Team [http://www.apache.org/press/index.html#whoweare]
   must review and coordinate releases for branding
   - On website and in release DISCLAIMER file:
   - Apache Podling-Name is an effort undergoing incubation at The Apache
      Software Foundation (ASF), sponsored by the name of Apache TLP sponsor.
      Incubation is required of all newly accepted projects until a further
      review indicates that the infrastructure, communications, and decision
      making process have stabilized in a manner consistent with other
successful
      ASF projects. While incubation status is not necessarily a reflection of
      the completeness or stability of the code, it does indicate that the
      project has yet to be fully endorsed by the ASF.
      - Website should include Apache Incubator logo:
      http://incubator.apache.org/guides/press-kit.html


   - Release should include:
      - DISCLAIMER
      - LICENSE
      - NOTICE - attribution notices


http://www.apache.org/legal/release-policy.html

   - A release must contain source package which is cryptographically
   signed by Release Managerlead with detached signature. It must be tested prior
   to voting for release.
   - Release must only contain appropriately licensed code
   - Please ensure you wait >=24 hours after uploading a release before
   making announcements so mirrors catch up
   - Releases of more than 1GB of artifacts require a heads-up to
   Infrastructure in advance.
   - Which directory for what build?
   http://www.apache.org/legal/release-policy.html#build-directories


http://www.apache.org/dev/release-distribution.html

   - Artifacts MUST be accompanied by:
      - apache-mxnet-src-0.10.1-incubating.asc - contains OpenPGP
      compatible ASCII armored detached signature
      - apache-mxnet-src-0.10.1-incubating.md5 - MD5 checksum
      - apache-mxnet-src-0.10.1-incubating.sha - SHA checksum (SHOULD)
   - Publish KEYS file in distribution directory root
      - Signing keys MUST be published in KEYS file, SHOULD be available in
      global public keyserver
      http://www.apache.org/dev/release-signing#keyserver, SHOULD be linked
      into web of trust
      - Keys MUST be RSA & 4096 bits


http://www.apache.org/dev/release-publishing.html

   - Apache RAT can assist in checking license compliance
   http://creadur.apache.org/rat/
   - Eventually we should set up a build system to sign our releases with
   cryptographic signatures. For now we’ll do it manually.


http://www.apache.org/dev/release-signing.html

   - Create a signature and sign releases as mentioned above

...