www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: Finishing release policy codification
Date Sun, 23 Aug 2015 02:59:02 GMT
On Sat, Aug 22, 2015 at 3:36 AM, sebb <sebbaz@gmail.com> wrote:
> The phrase is now:
> "... MUST only add binary/bytecode files that are the result of compiling
> that version of the source code release and its dependencies."
> This could mean either that the RM compiled the dependency from source,
> or they included a pre-compiled version of the dependency.
> Are both meanings intentional?

Yes.  My understanding of current policy is that when assembling "convenience
binaries", including pre-compiled versions of dependencies is permitted.

Consider that the alternative -- requiring that all dependencies must be
compiled locally -- yields marginal benefit at substantial cost.
Security-conscious consumers will shun convenience binaries as potential
trojan horses regardless, as they are produced on uncontrolled RM developer

> The title does not agree with the references elsewhere, so I already made
> the following change to the existing doc:
> s/Title: Releases Policy/Title: Releases Policy/

Nice catch -- I have committed a fix.

(I understand what you mean despite the typo in your s///: remove the trailing
"s", yielding "Release Policy" instead of "Releases Policy".)

> The policy appears to disallow *any* mention of snapshot builds on the
> website.

That is certainly not the intent.  Do the two last commits on this branch
address your concern?


> However historically this has been done on website pages which are
> solely directed at the development community.


The current release policy page has quite a lot to say on the
subject[1][2][3][4][5].  But it is not complicated, merely repetitive and
insistent.  The policy boils down to this:

*   A "developer community" is approximated for the purpose of release policy
    as "people following the dev list (or searching its archives)"
*   Unreleased materials, in any form, may only be shared within the developer

That is the only interpretation which is consistent with all passages in the
current release policy page.

There are arguments to be made that the policy should be more liberal, and
those arguments should be given a fair hearing -- but not now.  This
initiative is limited to codifying existing policy.

> Or can download pages mention snapshots if the caveats
> are documented?

Adding such language would be a policy change, and thus outside the scope of
this codification initiative.

> I assume snapshots can be mentioned in bug trackers?

Yes, clearly that is OK.  "Bug is fixed -- try tonight's snapshot!"

Issue trackers are a developer resource; anyone who is interacting with one is
participating in development.  Furthermore, a comment on an issue tracker
generally reaches a negligible number of people outside of the development

Now, since a user reporting a bug may not be "subscribed to the dev list (or
searching its archives)", this is a corner case bug in the definition of
"developer community".  I hope that the branch linked above fixes that bug.

Marvin Humphrey

[1] http://www.apache.org/dev/release#why

    Were we to avoid drawing this distinction, and instead encouraged users to
    interact directly with source control or nightly builds, it would be very
    difficult for the organization to offer legal protection to Apache
    committers and PMC members who have only exercised their own judgement in
    making software modifications without the benefit of an **authorized
    business decision** approving of the distribution of those artifacts as-is
    to the public at large.

[2] http://www.apache.org/dev/release#what

    During the process of developing software and preparing a release, various
    packages are made available to the developer community for testing
    purposes. **Do not include any links on the project website that might
    encourage non-developers to download and 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
    package. If you find that the general public are downloading such test
    packages, then remove them.

    Under no circumstances are unapproved builds a substitute for releases. If
    this policy seems inconvenient, then release more often. Proper release
    management is a key aspect of Apache software development.

[3] http://www.apache.org/dev/release#release-types

    - **Test Packages** are not Apache releases. All releases require due
    process and official approval. Test packages are for testing ongoing
    development and should only be discussed on the project development lists.

    - **Nightly Builds** are simply built from the Subversion trunk,
    usually once a day. These packages are intended for regular testing of
    the build process and to give automated testers a common build for
    regression testing. They are not intended for use by the general

    - **Release Candidates** are packages that have been proposed for
    approval as a release but have not yet been approved by the project.
    These packages are intended for developers (and users who follow the
    development discussions) to test and report back to the project
    regarding their opinions on the package quality compared to prior
    releases. Many release candidates are possible prior to a release
    approval. Users that are not interested in development testing should
    wait until a release is formally approved.

    - **Releases** are packages that have been approved for general public
    release, with varying degrees of caveat regarding their perceived quality
    or potential for change. Releases that are intended for everyday usage by
    non-developers are usually referred to as "stable" or "general availability
    (GA)" releases. Releases that are believed to be usable by testers and
    developers outside the project, but perhaps not yet stable in terms of
    features or functionality, are usually referred to as "beta" or "unstable".
    Releases that only represent a project milestone and are intended only for
    bleeding-edge developers working outside the project are called "alpha".

[4] http://www.apache.org/dev/release#host-rc

    Test packages are for use by consenting developers and interested
    community members only, so they should not be hosted or linked on pages
    intended for end users.  They should not be mirrored; only blessed GA
    releases should be mirrored.

[5] http://www.apache.org/dev/release#build-directories

    | Type             | Location                 |
    | Nightly Builds   | people.apache.org/builds |
    | Current Releases | www.apache.org/dist      |
    | Older Releases   | archive.apache.org/dist  |

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

View raw message