www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com.INVALID>
Subject Re: Release Policy clarification inititiative
Date Thu, 12 Jun 2014 18:45:17 GMT
What is all this stuff about REQUIRED individual testing as a prerequisite to a vote?  Most
IPMC votes would be invalidated by this, are you sure this is what
you want versus RECOMMENDED?

On Wednesday, June 11, 2014 10:35 PM, Marvin Humphrey <marvin@rectangular.com> wrote:


As many of you know, an initiative to clarify Apache's release policy was
launched a couple weeks back on legal-discuss@apache:


I would be grateful to receive your expert review of the draft policy,
attached below.  The version control history is available here:


For changes adopted in response to feedback so far on legal-discuss@apache,
see here:


While the conversation was underway on legal-discuss@apache, I was made aware
of Infra's long-standing responsibilities as steward of release policy.  It is
regrettable that I did not realize Infra's role earlier and launch the
initiative here instead.  For a more complete explanation, see

In between the tailing off of the legal-discuss thread and now, the Board has
determined that going forward, the Legal Affairs committee will be tasked with
development and oversight of the Release Policy as captured in clarified
document (once it is approved), which covers mainly legal aspects.  Infra will
continue to maintain ownership over aspects relating to how release policy is
implemented on our infrastructure.

I had originally envisioned that the current policy page would be divided into
distinct "Release Policy" and "Release FAQ" sections but would continue to
live in its current location.  However, it may be that such a plan is
impractical, so here is a potential alternative:

*   Establish a new home for the policy at <www.apache.org/legal/release>.
*   Set up a permanent redirect from the current home under /dev to the new
    location under /legal.
*   Formalize a "Release Distribution Policy" curated by Infra which would
    live at <www.apache.org/dev/distribution> and house aspects of the current
    policy page which should not move under /legal (and possibly other
    concerns as well).
*   Establish links between the new "Release Policy" and "Release Distribution
    Policy" pages.


Marvin Humphrey


# Release Policy # {#policy}

## Definition of "release" ## {#release-definition}

Generically, a release is anything that is published beyond the group
that owns it.  For an Apache project, that means any publication outside the
developer community, defined as the subscribers to the product dev list.

More narrowly, an official Apache release is one which has been endorsed as an
"act of the Foundation" by a PMC.

## Release approval ## {#release-approval}

Each PMC MUST obey the ASF requirements on approving any release.

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.
Votes cast by PMC members are binding.

Before casting +1 binding votes, individuals are REQUIRED to download all
signed source code packages onto their own hardware, verify that they meet all
requirements of ASF policy on releases as described below, validate all
cryptographic signatures, compile as provided, and test the result on their
own platform.

Release votes SHOULD remain open for at least 72 hours.

## Publication ## {#publication}

Projects SHALL publish official releases and SHALL NOT publish unreleased
materials outside the developer community.

During the process of developing software and preparing a release, various
packages are made available to the developer community for testing
purposes. **Projects MUST NOT take any action that might
encourage non-developers to download or use nightly builds, snapshots,
release candidates, or any other similar package.** The only people who are
supposed to know about such packages are the people following the dev list
(or searching its archives) and thus aware of the conditions placed on the

## Artifacts ## {#artifacts}

### Source packages ### {#source-packages}

Every ASF release MUST contain one or more source packages, which MUST be
sufficient for a user to build and test the release provided they have
access to the appropriate platform and tools.

### Release signing ### {#release-signing}

All supplied packages MUST be cryptographically signed by the Release
Manager with a detached signature.  Folks who vote +1
for release MAY offer their own cryptographic signature to be concatenated
with the detached signature file (at the Release Manager's discretion)
prior to release.

### Compiled packages ### {#compiled-packages}

The Apache Software Foundation produces open source software. All releases
are in the form of the source materials needed to make changes to the
software being released.

As a convenience to users that might not have the appropriate tools to build a
compiled version of the source, binary/bytecode packages MAY be distributed
alongside official Apache releases.  In all such cases, the
binary/bytecode package MUST have the same version number as the source
release and MUST only add binary/bytecode files that are the result of
compiling that version of the source code release.

## 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

## Licensing Documentation ## {#licensing-documentation}

Each package MUST provide a `LICENSE` file and a `NOTICE` file which account
for the package's exact content.  `LICENSE` and `NOTICE` MUST NOT provide
unnecessary information about materials which are not bundled in the package,
such as separately downloaded dependencies.

For source packages, `LICENSE` and `NOTICE` MUST be located at the root of the
distribution.  For additional packages, they MUST be located in the
distribution format's customary location for licensing materials, such as the
`META-INF` directory of Java "jar" files.

### The `LICENSE` file ### {#license-file}

The `LICENSE` file MUST contain the full text of the [Apache License

When a package bundles code under several licenses, the `LICENSE` file
MUST contain details of all these licenses. For each component which is not
Apache licensed, details of the component MUST be appended to the `LICENSE`
file.  The component license itself MUST either be appended or else stored
elsewhere in the package with a pointer to it from the `LICENSE` file, e.g.
if the license is long.

### The `NOTICE` file ### {#notice-file}

The `NOTICE` file must conform to the requirements of [Apache licensing

See also [section 4(d)](licenses/LICENSE-2.0.html#redistribution) of the
Apache License 2.0.

### License Headers ### {#license-headers}

Source files consisting of works submitted directly to the ASF by the
copyright owner or owner's agent must contain the appropriate [ASF license

## Release Distribution ## {#release-distribution}

Once a release is approved, all artifacts MUST be uploaded to the project's
subdirectory within the canonical Apache distribution channel,

The PMC is responsible for the project distribution directory and MUST be able
to account for its entire contents.  All release artifacts within the
directory MUST be signed by a committer, preferably a PMC member.

After uploading to the canonical distribution channel, the project (or anyone
else) MAY redistribute the artifacts in accordance with their licensing
through other channels.

### Release Archival ## {#release-archival}

All official releases MUST be archived permanently on archive.apache.org.

(Uploading to the canonical distribution channel satisfies this requirement
because archival happens automatically as a side effect.)

## Release Policy Administration ## {#administration}

Projects MUST notify the Board of Directors of any deviations from recommended
or required policy directives.

Changes to Release Policy must be approved by Legal Affairs.


Formalize additional official policies and reference them from this policy:

*   _ASF Licensing Policy_ (curated by Legal Affairs, applies to both released
    and unreleased code)
*   _ASF Release Distribution Policy_ (curated by Infrastructure)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message