collecting signatures for releases: thoughts on collect_sigs.py@{2011-12-04}

[Daniel Shahaf <d....@daniel.shahaf.name>]

[ Summary: collect signatures for releases via a CGI that verifies
signatures and commits them to a Subversion repository. ]


We now have a CGI script[1] that collects the signatures for release,
verifies them, and assembles them into *.asc files.  That automates
some work that previously fell upon the release manager.

Several features were suggested for the CGI:

* verify signatures as they are being collected [this was present in the CGI from day one]
* allow anyone (not just the RM) to retrieve collected signatures [this was implemented last week]
* notify dev@ upon new signatures
* notify IRC upon new signatures
* display statistics about the collected signatures

It seems to me that we could meet most of these requirements ---
specifically, the second, third, and fourth --- by storing the
signatures in a Subversion repository.  We could continue meeting
the first requirement by using the signature-verifying CGI as a doorway;

Specifically, the suggested process is:

* Signatures would be entered into the CGI.
* The CGI would verify them (like today).
* The CGI would then commit them to the backing repository. 
* Notification to dev@/IRC will be handled by standard post-commit hooks.

This addresses all but the 'statistics' criterion (which includes, for
example, reporting how many signatures each tarball currently has and
how are they distributed between Unix/Windows).

Thoughts?

Daniel


[1] http://work.hyrumwright.org/pub/svn/collect_sigs.py
    http://svn.apache.org/repos/asf/subversion/trunk/tools/dist/collect_sigs.py

What repository to use? Re: collecting signatures for releases: thoughts on collect_sigs.py@{2011-12-04}

[Daniel Shahaf <d....@daniel.shahaf.name>]

Daniel Shahaf wrote on Sat, Dec 04, 2010 at 00:51:12 +0200:
> the backing repository [where *.asc files are maintained prior to blessing the release]

For 1.6 we can use the subversion.tigris.org repository (to which
blessed tarballs are eventually committed).  It's not configured
for CIA though.

For 1.7+ we can could use either https://dist.apache.org/repos/dist/dev/
or a subtree of https://svn.apache.org/repos/asf/subversion/.  Both of
them are (or can be) tied to CIA and mailer hooks.

According to pquerna, the 'dev' area of the dist/ repository is an
appropriate place to collect votes for not-yet-blessed releases.  The
dist/ repository is also tied to the ASF's mirroring system via
svnpubsub: the master distribution directories are svnpubsub slaves of
that repository.