Voting on Apache Releases is not that hard

After many years of working with Apache Cordova I got into how Apache Cordova is being developed and how the process of a new release works. A “release” of an Apache project is considered an official publication of the Apache Software Foundation. For this post I am talking about Apache Cordova but much of this applies exactly to other Apache projects

If you want to know more about Apache releases please go to the offical release policy. I will now go into how I vote on releases of other PMC members. Preparing releases myself as a release manager is a different story.

Why do we vote?

Apache has a definition of what a release is and that it requires a vote.

An Apache release is a set of valid, signed, artifacts, voted on by the appropriate PMC and distributed on the official ASF release infrastructure. See below for discussion of the words in bold, all of which are essential.

The purpose of the vote is to check that a release is done properly by checking the licensing requirements and signature and more importantly that the community agrees on the release. At Apache it is all about creating software as a community.

What is a vote?

A vote starts with an email with [VOTE] in the subject sent to the development mailing list. The emails tells everybody which project or subproject is going to be released, where to download the so-called release candidate and some information what to check. Everybody can now respond to that email thread with their vote and things they checked before voting.

Generally a vote is saying “I vote +1” to approve the release or “I vote -1” to raise concerns. Everybody can and is encouraged to vote but only votes by PMC members are binding. If you are interested in some release feel free to subscribe to the mailing list and vote on releases. We at Cordova appreciate any vote and testing of a release.

A vote passes if it gets more +1 votes than -1 votes. At Cordova a vote runs a minimum of 48 hours but sometimes longer to get the chance for people to vote. If a vote passes the release becomes official and the release manager does the final steps to publish the release. If a vote fails usually somebody fixes the issues quickly and starts a new vote for the new release candidate.

You can checkout some votes in the mailing list archives.

What I check before casting a +1 vote

At Cordova we have quite a bit of tooling that makes voting on releases a quick task of you got practice and know what to check. The hard part is to setup your development environment and local tools that is explained here.

If your GPG and our tool with some useful commands called coho are ready to go you can get to the vote email and start checking the required things. The official documentation what must be checked by PMC members is in this document.

So now this is usually my set of steps while voting. I may change the order a bit, add some additional steps particular for one release or leave some steps out but you might get some ideas on what to check for your vote:

• Open vote email :-)
• create a new folder for the files
• downloading all release artifacts from the linked dist-dev directory in the email with wget
• run coho verify-archive .... and checking the output if signature and hash are correct
• extract the archive with tar -xzf ...
• go into the extracted package directory and run npm install
• check version number
• check the npm audit output
• check if LICENSE and NOTICE file exist
• clone or update the projects repository in my apache folder
• check the release tag with coho verify-tags and the string from the email
• npm install and audit in the repository
• run local tests with npm test
• check license headers with coho audit-license-headers
• check CI runs for tag

-> reply to the email thread with my vote (+1 or -1) and a list of steps I checked

If I find something I will now reply to the DISCUSS thread of the vote talk about the issues I found.

These are a lot of steps. Depending on the size of the release or project I might skip many of them. The bold ones are the most important ones to me. As Cordovas official vote document says all the important checks are done by the release manager. You as a voter just have to check the release is signed and created properly from the code it should be.

You also don’t need to run tests on features or bug fixes. Everything should be tested before it gets merged. You don’t have to do all these steps to do a proper vote. These are just some ideas on what to check be more sure the release is in a good condition.

It’s important for Apache projects to have some votes that take not too long. As a release manager it’s tiring having to wait for many days or event weeks to finish a release. Voting is really not hard or takes a lot of time so if you are interested just give it a try.