www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Clarified Release Policy
Date Fri, 23 May 2014 23:09:42 GMT

I'm starting a new thread to respond to specific feedback about the proposal
because the original thread has fragmented.

To reiterate: The goal of this initiative is to clarify policy, NOT TO

On Fri, May 23, 2014 at 4:58 AM, sebb <sebbaz@gmail.com> wrote:
> On 22 May 2014 19:42, Marvin Humphrey <marvin@rectangular.com> wrote:

>> For a release vote to pass, a minimum of three positive votes and more
>> positive than negative votes MUST be cast.  Releases may not be vetoed.
> Is there currently a requirement that VOTEing should be by majority vote?


Here is the original language:

    Votes on whether a package is ready to be released use [majority
    -- i.e., at least three PMC members must vote affirmatively for release,
    and there must be more positive than negative votes.  Releases may not be

Here is the relevant changeset:


>> Votes cast by PMC members are binding.
> _Only_ votes cast ...

I believe that omitting "only" is slightly more accurate, because the
Incubator has obtained permission from the Board for PPMC votes to be binding
under certain strict conditions.  However, if there is consensus that the
"only" qualifier should be added I am amenable.  Regardless, the policy is
that PMC votes alone are binding until the Board grants an exception.

>> Before casting +1 binding votes, individuals are required
>> to download the signed source code package onto their own hardware, compile it
>> as provided, and test the resulting executable on their own platform, along
>> with also validating cryptographic signatures and verifying that the package
>> meets the requirements of the ASF policy on releases.
> I think there should be a requirement to ensure that the contents of
> the source package agrees with the SCM tag, as that is the only
> practical way to ensure provenance of the released code.

I perform that check myself when verifying releases and I agree that it is a
best practice.  However, it is not currently required and adding it would be a
policy change.

>> ## Licensing ## {#licensing}
>> Every ASF release MUST comply with ASF licensing policy. This
>> requirement is of utmost importance and an audit SHOULD be performed before
>> any full release is created.  In particular, every artifact distributed MUST
>> contain only appropriately licensed code per [Apache Licensing
>> Policy](/legal/resolved).
> I think this implies that every file in the source release must be
> traceable back to a file in the SCM tag.

I don't think that interpretation holds up to close scrutiny.  For background,
see this post from Leo Simons: http://markmail.org/message/2ncepopzgnshtyd6

>> The PMC is responsible for the project distribution directory and MUST be able
>> to account for its entire contents.  All artifacts within the directory MUST
>> be signed by a committer, preferably a PMC member.
> This is a bit restrictive - frequently the dist directory contains
> text files such as release notes or package descriptions.
> I don't think any projects currently provide hashes or sigs for such
> additional files.

The language of the current policy has that flaw:

    Note that the PMC is responsible for all artifacts in their distribution
    directory, which is a subdirectory of www.apache.org/dist/ ; and all
    artifacts placed in their directory must be signed by a committer,
    preferably by a PMC member. [...]

One possible fix is to say "All release artifacts" instead of "All artifacts":


>> ### Release Archival ## {#release-archival}
>> All official releases MUST be archived permanently on archive.apache.org.
> [Could note that this occurs automatically as part of a cron job]

Yes, I'd thought about that.  We could handle it in an FAQ.  But here's a
change to the policy text:


Thank you for your feedback, sebb!

Marvin Humphrey

To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message