couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "Binary_Releases" by DaveCottlehuber
Date Fri, 10 Feb 2012 19:49:53 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The "Binary_Releases" page has been changed by DaveCottlehuber:
http://wiki.apache.org/couchdb/Binary_Releases?action=diff&rev1=82&rev2=83

Comment:
v1 ready for 1.2.0 release

  ## page was copied from Release_procedure
  <<Include(EditTheWiki)>>
+ 
+ This page details how Windows binaries are validated and voted on. Any Apache CouchDB committer
is free to make a binary snapshot or release, but they are usually made by the release team.
There is an important distinction between snapshots and releases, namely:
+ 
+  * Snapshots may be provided at any time, and have no significance or expectations attached
to them
+  * Releases must be cut from the same source tag or commit sha used for a preceding Source
Release
+ 
+ This distinction ensures that the user community can rely on the same functionality cross-platform
for Releases, and that the developer community is not obligated to maintain or support snapshots.
+ 
+ <<TableOfContents(2)>>
+ 
+ = Introduction =
+ 
+ Following an official source vote, a Windows binary is created. The procedure for this is
documented in [[https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob;f=INSTALL.Windows;hb=HEAD|INSTALL.Windows]]
and a scripted approach is available in the appropriate branch of [[https://github.com/dch/glazier/|glazier]].
+ 
+ After the binary is built, it is then [[http://www.apache.org/dev/release-signing.html#sign-release|signed]]
and uploaded to the appropriate committer's [[https://people.apache.org/~id|apache site]].
+ 
+ The release manager will send a notice to the [[mailto:user@couchdb.apache.org|user@ mailing
list]], requesting a vote on the new artefact. This follows the general [[Release_procedure|CouchDB
release procedure]].
+ 
+ = Testing  =
+ 
+ Overall we are interested that the binary is malware free, correctly signed, and digests
match, and functionality matches that of the original source tarball.
+ 
+  * [[http://www.apache.org/info/verification.html|Verify]] the GPG [[http://www.apache.org/dev/release-signing.html#verifying-signature|signature]].
Additional tips are available at [[http://gpg4win.de/handbuecher/novices.html|Introduction
to GPG for Windows]].
+  * Validate the MD5 and SHA digests using [[http://md5deep.sourceforge.net/| md5 and sha
for Windows]] or similar
+  * Unpack the archive either directly or using the [[http://innounp.sourceforge.net/|Inno
setup unpacker]]
+  * Confirm using antivirus software there are no viruses or malware present. Microsoft provides
the free [[http://windows.microsoft.com/en-GB/windows/products/security-essentials|Security
Essentials]].
+  * Double-check `README`, `INSTALL.Windows`, `NEWS`, `LICENSE`, and `CHANGES` files are
present in {{{%COUCHDIR%/share/doc/couchdb/}}} and contents is appropriate. At present these
are gzipped but this should be fixed, and added as shortcuts.
+  * If required, run the installer into a separate directory and start CouchDB via the provided
{{{couchdb.bat}}} script.
+  * Run Firefox >=4, launch Private Browsing mode, and disable caching by setting both
{{{browser.cache.disk.enable = false}}} and {{{network.http.use-cache = false}}} temporarily.
+  * Use Futon to run the basic [[http://127.0.0.1:5984/_utils/verify_install.html|user verification]]
tests as well as the full [[http://127.0.0.1:5984/_utils/couch_tests.html?script/couch_tests.js|dev
test suite]].
+  * Some tests may periodically depending on the speed of your PC and the phases of the moon.
It's fine to re-try a few times, or to test over LAN connection rather than localhost.
+ 
+ = Voting and Voters =
+ 
+  * [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/200907.mbox/%3C20090716211304.GA17172@tumbolia.org%3E|Call
a vote]] on the [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]] mailing
list.
+  * Ensure you link to the [[Binary_Releases#Testing|test procedure]].
+ 
+ If you are voting:
+ 
+  * Reply to the original Binary Release announcement - for example; {{{
+ +1
+ Windows 7 x64
+ Firefox 10.12
+ signature OK
+ md5 & sha OK
+ No malware
+ Futon tests failed
+ [... tedious details ommitted.. ]
+ }}}
+ 
+  * After 72 hours have elapsed without any -1 votes, and with at least 3 +1 votes, send
a confirmation.
+  * If aborted, ensure a summary is sent out with any follow-up actions required, and by
whom.
+  * Full details are on the main CouchDB [[Release_procedure|Release procedure]].
+ 
+ = Release =
+ 
+ On a successful vote, three things must be updated:
+ 
+  * Approved binaries with sha/md5/asc keys to be moved into the {{{dist}}} environment
+  * Subsequent update of CouchDB downloads page
+  * Once these are available on mirrors, the confirmation announcement can be sent.
  
  = NOTES =
  
   * currently working with HTTPD team to see if the new fancypants code signing is usable
   * will likely roll releases of 1.2.0 in the usual fashion and use pgp keys to validate
it
+  * still need way of referencing the detailed build process, and labelling artefacts.
-  * check with nslater on best way to handle this; I guess package/vote/upload is simplest
-  * also need to sort out where to host the damn thing. infra@ says people.a.o is not good
-  for the actual releases; mirrors might be OK for the releases though. Snaps have to go
-  somewhere, I am still partial to github simply because it tracks the number of downloads
-  when considering retiring them.
-  * most important issue ATM is how to reference the build process as I continually fiddle
-  with it, and how to name the artefacts consistently.
- 
- == Making a Binary Release [DRAFT] ==
- 
- Any Apache CouchDB committer is free to make a binary snapshot or release, but they are
usually made by the release team. There is an important distinction between snapshots and
releases, namely:
- 
-  * Snapshots may be provided at any time, and have no significance attached to them.
-  * Releases must be cut from the same source tags or commit used for a preceding Source
Release
- 
- This distinction ensures that the user community can rely on the same functionality cross-platform
for Releases.
  
  If you'd like to help out with making a release, lets us know on the [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]]
mailing list.
  
- === Checklist ===
- 
-  * Check out the source code via git; for releases using the appropriate tag referred to
in the Source Release announcement.
-  * Double-check `README`, `INSTALL.Windows`, `NEWS`, and `CHANGES` files
-  * Download prebuilt Erlang/OTP and CouchDB pre-requisite libraries if required
-  * Make the build, including the final installer package
-  * On a fresh system, first 
- 
- === Preparing the Community ===
- 
- Call a vote on the [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]]
mailing list asking for a request for comments on the release. Ask all developers to specifically
check the `NEWS` and `CHANGES` file for anything that has been added in this release.
- 
- === Preparing the Release ===
- 
- It is generally a good idea to work under a clean temporary directory.
- 
- You can then run the following commands:
- 
- {{{
- git archive --prefix=Y.Y.Y/ -o Y.Y.Y.tar <tree-ish>
- tar xf Y.Y.Y.tar
- }}}
- 
- You must then use the `Y.Y.Y` directory to prepare the release.
- 
- === Release Signing ===
- 
- You will need a GPG key pair to sign the release.
- 
- If you do not have one already, see the Useful Resources section for more help.
- 
- It is generally better if your key is also signed by other people.
- 
- Your public key must be added to:
- 
-  * http://www.apache.org/dist/couchdb/KEYS
- 
- You should also upload your key to a public key server for good measure.
- 
- Edit Makefile.am so that `gpg` uses your key ID.
- 
- ''We should probably make this a command line option.''
- 
- You can find your key ID by running:
- 
- {{{
- gpg --list-keys
- }}}
- 
- 
- === Creating the Release Artefacts ===
- 
- To build the source for distribution you should then run the following command:
- 
- {{{
- ./bootstrap && ./configure && make distsign
- }}}
- 
- If everything was successful you should see the following files in the working directory
ready for distribution:
- 
-  * apache-couchdb-Y.Y.Y.tar.gz
-  * apache-couchdb-Y.Y.Y.tar.gz.asc
-  * apache-couchdb-Y.Y.Y.tar.gz.md5
-  * apache-couchdb-Y.Y.Y.tar.gz.sha
- 
- === Checking the Release Contents ===
- 
- Create a temporary directory:
- 
- {{{
- mkdir /tmp/couchdb
- }}}
- 
- Move the release files to the temporary directory:
- 
- {{{
- mv apache-couchdb* /tmp/couchdb
- }}}
- 
- Change to the temporary directory:
- 
- {{{
- cd /tmp/couchdb
- }}}
- 
- Then unpack another copy of the source tarball
- 
- {{{
- tar xf Y.Y.Y.tar
- }}}
- 
- Then compare the tarball with the exported tag directory:
- 
- {{{
- diff -r apache-couchdb-Y.Y.Y Y.Y.Y
- }}}
- 
- Use your judgment here to figure out if anything is missing, or has been included by mistake.
- 
- Upload the release files to your `public_html` directory on `people.apache.org` and make
sure they are world readable.
- 
- Do not upload the exported tag directory, of course. That was only for testing.
- 
- === Calling a Vote ===
- 
-  * [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/200907.mbox/%3C20090716211304.GA17172@tumbolia.org%3E|Call
a vote]] on the [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]] mailing
list.
-  * Make sure to link to the [[Test_procedure|test procedure]] page.
-  * When the vote passes, send a [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/200907.mbox/%3C20090722214200.GA11737@tumbolia.org%3E|summary
of the vote]] to the [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]]
mailing list.
- 
- The vote email must include the full tree-ish used to prepare the release.
- 
- The release manager has the power to abort a vote at any point and for any reason.
- 
- Please try to make it a good one though!
- 
- A vote can only pass if there are at least three +1 votes. These votes can come from anyone,
including non-committers, and in fact, everyone is encouraged to partake in and vote on each
release. However, it is preferable that at least three +1 votes come from the committers,
or better yet, the PMC. Once three +1 votes have been counted, the vote can pass. However,
if anyone votes -1 or expresses any serious concern, that should be addressed. Usually, this
will be cause to abort the vote. A vote can only be closed after three working days. This
allows most people a chance to test and vote on the release.
- 
- === Making the Release ===
- 
-  * Create a signed tag, using the same key as used to signed the release, pointing to the
release tree-ish and a link to the [VOTE RESULTS] message on the dev mailing list.
-  * Push the signed tag with 'git push origin Y.Y.Y'.
-  * Copy the release directory to `/www/www.apache.org/dist/couchdb` on `people.apache.org`.
-    * Make sure that the release directory and all the files within it are owned by the `couchdb`
group and are group writable.
-  * Wait for all changes to be synced to public mirrors.
-  * Update http://couchdb.apache.org/downloads.html
-  * Wait for all changes to be synced to the public site.
-  * Make a [[http://mail-archives.apache.org/mod_mbox/www-announce/201007.mbox/%3C029B8F80-6C99-41C0-B47C-A334667E25BA@apache.org%3E|release
announcement]] to the [[http://mail-archives.apache.org/mod_mbox/www-announce/|announce]],
[[http://mail-archives.apache.org/mod_mbox/couchdb-user/|couchdb-user]], and [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]]
mailing lists.
- 
- At each stage of the actual release, it is expected that a person can follow the trail of
changes back to the source. Because most of these systems are slow, things must be done in
the correct order. It would be unfortunate if `downloads.html` listed a release that was not
available on a local mirror, or that was missing a corresponding tag in the Git repository.
The changes should always propagate from the source, to the `dist` directory, to the mirrors,
to `downloads.html`, and finally to the actual release announcement.
- 
- === Doing Housekeeping ===
- 
-  * Add a new release section to `NEWS` and `CHANGES` on trunk if not already present.
-  * Add a new release section to `NEWS` and `CHANGES` on Y.Y.x the branch if not already
present.
-  * Add "version has not been released" warnings to these release sections if not already
present.
-  * [[https://issues.apache.org/jira/secure/project/ManageVersions.jspa?pid=12310780|Update
versions]] in JIRA.
-    * If the currently released version is 0.1.0, JIRA should have options for 0.1.1, 0.2.0,
and 0.3.0.
-    * The released version should be marked as released in JIRA.
-  * Update the links on this page to most recent email archives.
-  * Update branches, trunk, and site with security changes not documented in the released.
-  * Call a discussion on the [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]]
mailing list about archiving old releases.
-    * To archive an old release, remove it from `downloads.html` and then delete the corresponding
directory from the `dist` directory. Do not worry about the release artefacts no longer being
available, they are automatically mirrored to the Apache archive site and will remain there
even after they are deleted from the main `dist` directory.
- 
- == Useful Resources ==
- 
-  * http://www.apache.org/dev/release.html
-  * http://incubator.apache.org/guides/releasemanagement.html#best-practice
-  * http://www.apache.org/foundation/voting.html
-  * http://www.apache.org/dev/openpgp.html
-  * http://www.apache.org/dev/release-signing.html
-  * http://www.apache.org/info/verification.html
- 

Mime
View raw message