www-release-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hyrum K. Wright" <hyrum_wri...@mail.utexas.edu>
Subject Re: Release process tooling
Date Mon, 26 Jul 2010 16:24:01 GMT
On Mon, Jul 26, 2010 at 11:03 AM, Paul Querna <pquerna@apache.org> wrote:
> On Thu, Jul 22, 2010 at 11:37 AM, Hyrum K. Wright
> <hyrum_wright@mail.utexas.edu> wrote:
>> I've been thinking a bit lately about the way we can provide better
>> tools for projects to release.  The overarching goal is to provide
>> tools which reduce the barriers for projects to create high-quality
>> verified and signed releases.  This is a brain dump of my thoughts,
>> with which I'd like to stimulate some discussion.
>> There are a lot of bikeshedable components, but generally I'm thinking
>> about the following workflow:
>>  * RM creates artifact(s)
>>  * RM signs the artifact(s)
> for httpd:
>  <https://svn.apache.org/repos/asf/httpd/site/trunk/tools/release.sh>

Sure, and Subversion has its own version of a tool to create release
artifacts.  I think this bit is largely project-dependent.

>>  * RM registers the artifact(s) using a script on {people,dist,?}.apache.org
>>  * PMC members go to a webapp to download the artifact(s)
>>  * offline, the PMC members verify and sign the artifact(s)
>>  * PMC members then upload signatures through the webapp
>>  * webapp verifies:
>>    a) the signature is valid
>>    b) the signer is authorized to sign the artifact(s) (i.e., is a
>> member of the PMC)
>>  * RM retrieves the signatures via script or webapp
>>  * RM can then run script to promote the artifact(s), with signatures
>> and hashes, to the distribution area
>> Some of this reflects my own bias as the Subversion RM for the past
>> couple of years, but a lot of it is the result of various
>> conversations with Paul, Henri and other folks.  Aside from the
>> questions of storage and other minutiae, am I missing anything?
> I think most of it makes sense.  I wonder though if some of this is
> best served by a command line tool making http calls -- just so you
> can do things like pipe signatures to a local gpg instance for
> validation in a more semi-automated way, might be an easier interface
> for some tasks than a webapp.  Either way, it still relies upon
> getting a webapp going, we can make other interfaces for a better user
> experience later.

Either a command-line tool or a webapp.  They can both be front-ends
to the same database/script/files/whatever that is tracking the state
of the release artifacts.  Maybe that's the thing that needs to be
designed first (or maybe it's as simple as a set of flat files in a
svn repo).


View raw message