Versions Compared

Old Version 68

changes.mady.by.user Meghna Baijal

Saved on

compared with

New Version 69

changes.mady.by.user Meghna Baijal

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

2. Running the voting process for a release:

...

  1. Vote on dev@ 

The full voting process is two phases: 3 days on dev@mxnet.apache.org, 3 days on http://general@incubator.apache.org.

...

EMAIL TEMPLATE: OPENING A VOTE TO DEV@

To: dev@mxnet.apache.org
Subject: [VOTE] Release MXNet version 0.11.0.RC#
 
This is the vote to release Apache MXNet (incubating) version 0.11.0. Voting will start now and close $utc_now+72.
Link to release notes: <Link>
Link to release candidate 0.11.0.rc0: <Link>
Link to pip build: <Link>

 

Please remember to TEST first before voting accordingly:
+1 = approve
+0 = no opinion
-1 = disapprove (provide reason)

 

 

...

         2. Send out the Vote Results on dev@

EMAIL TEMPLATE: VOTING RESULTS

 
To: dev@mxnet.apache.org
Subject: [RESULTS] [VOTE] Release MXNet version 0.11.0.RC#
 
This vote passes with 7 +1 votes (3 bindings) and no 0 or -1 votes.
+1 votes
PMC Members:
* $Name
* $Name 
* $Name
 
Committers:
* $Name
* $Name
 
Community:
* $Name
* $Name
 
0 votes
* No votes
 
-1 votes
* No votes
 
Vote thread:
https://lists.apache.org/list.html?commits@mxnet.apache.org/
I'll continue with the release process and the release announcement will follow in the next few days.

 

...

 

...

$RM

...

  3. Triage issues and revote if necessary 

Should any vote fail to reach quorum or release manager determines that another RC needs to go out, the release manager 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.

 

EMAIL TEMPLATE: CANCEL A VOTE

To: dev@mxnet.apache.org
Subject: [CANCELLED] [VOTE] Release MXNet version 0.11.0.RC#
    We are CANCELLING this vote because...
    We will address this issue and send out RC#+1 for another vote.

 

         4. Start a vote on general@

EMAIL TEMPLATE: OPEN A VOTE TO GENERAL@

This is a call for a releasing Apache MXNet #.#.#-incubating, release
candidate #.

Apache S2Graph community has voted and approved the release.

Vote thread:
https://lists.apache.org/#######

Result thread:
https://lists.apache.org/#########

The source tarball, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/mxnet/########

The tag to be voted upon is v0.2.0-incubating-rc3:
<link>

The release hash is #########:
<link>

Release artifacts are signed with the following key:
<link>

KEYS file available:
<link>

For information about the contents of this release, see:
<link to release notes>

The vote will be open for 72 hours.

[ ] +1 Release this package as 0.1.0
[ ] +0 no opinion
[ ] -1 Do not release this package because...

...

Enjoy an adult beverage (or bubble tea) of your choice, and congratulations on making a MXNet release.

 

...

4. Process for a Patch Release

The patch release work should begin only once the major version release has been completed and announced.

Step 1: Cherrypick all the necessary bugfixes into the existing release branch

Step 2: Add a PR to update the version number etc only to this release branch first (https://github.com/apache/incubator-mxnet/commit/e0c7906693f0c79b0ce34a4d777c26a6bf1903c1)

Step 3: make sure the release branch build passes on builds.apache.jenkins

Step 4: Nightly tests should also pass (this maybe optional if there are no major code changes). Website should be built locally too. 

Step 5: Now tag the commit in github with the patch release tag - example 0.12.1

Step 6: Clone, tar and Sign the src code. 

Step 7: Validate the signatures

Step 8: Complete Docker, pip and website releases.

Step 9: Upload the src tar to the final destination - which is?

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 Manager 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

...