commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?
Date Mon, 14 Oct 2013 08:49:44 GMT
On 14/10/2013 09:41, Henri Yandell wrote:
> On Mon, Oct 14, 2013 at 12:16 AM, Mark Thomas <> wrote:
>> On 14/10/2013 02:55, Henri Yandell wrote:
>>> On Tuesday, October 8, 2013, Benedikt Ritter wrote:
>>>> Hi,
>>>> one of the points that seem to always come up once in a while is the
>>>> process of releasing components. I've never done it myself so I'm asking
>>>> people who have done it:
>>> I find myself wondering why a release vote is anything more than:
>>>   "I propose that r6525 of <dir> be tagged as 3.2. What say ye all?"
>>> That might focus us on the #1 step of whether the API and code is good
>> and
>>> relegate all the artifact juggling to a post release step. The tag (or
>> src
>>> tarball of the scm dir) is the important thing - the rest is artifact
>>> pain/noise and could be handled by different people.
>>> As it is we have a long laundry list of steps to master and get by the 3
>> or
>>> 4 RC fails before a release is done. And the list is always changing. Too
>>> much expertise is needed. It also makes us Maven specific, which may
>> limit
>>> us if we think broader in the future. We' turn down a JavaScript
>> component
>>> because I doesn't fit in with out release process.
>>> I propose release votes be simple revision based requests and involve no
>>> artifact churn :)
>> No can do. ASF policy requires that release votes are on source
>> releases, not svn tags or revision numbers.
> A semantic difference.

But an important one.

> Note that our votes in Commons require that we
> identify the svn tag/url and revision the source tarball came from already
> - ie) the source release isn't trusted unless we show where it came from
> [assuming that's still done]. So in reality the vote is on an svn tag and
> revision number, not a source release.
> To meet policy, all I need is: "I propose a vote on r5434 of <url>. Here is
> a source tarball I made in 2 minutes of svn export and tar. "

And that would be fine.

> And to curtail the next likely objection, I can also pgp sign that tarball
> if it's required so you know it's from me (not that it's required that my
> pgp be in the web of trust).

That objection wouldn't arise until you tried to publish the release. At
that point the signature is required and no it doesn't have to be in the
web of trust (although there are advantages if it is).

Your public key does need to be in the KEYS file for the project.

> You were happy with me committing to SVN, why
> we need a second set of credentials is beyond me (ie: the ASF itself should
> sign things, I sign when I type my SVN password).

An ASF wide signing service has been discussed a number of times but it
is non-trivial to do so securely. To date, no-one has had the time and
inclination to move the various proposals forward to a conclusion.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message