www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Finishing release policy codification
Date Sun, 23 Aug 2015 03:48:47 GMT
 Please don't create a binary policy that would prevent the inclusion of binaries created by
third parties. Such must be disclosed, but I think that doing so might prevent Apache OpenOffice
from releasing binaries. This would potentially impact 100,000,000 end users.

In the case of AOO my concern is mainly different language dictionaries from the over 40 that
are supported.

Regards,
Dave

Sent from my iPhone

> On Aug 22, 2015, at 7:59 PM, Marvin Humphrey <marvin@rectangular.com> wrote:
> 
>> 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
> machines.
> 
>> 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?
> 
>    https://github.com/rectang/asfrelease/commits/unreleased_dist_v1
> 
>> However historically this has been done on website pages which are
>> solely directed at the development community.
> 
> Indeed.
>> 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
> machines.
> 
>> 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?
> 
>    https://github.com/rectang/asfrelease/commits/unreleased_dist_v1
> 
>> However historically this has been done on website pages which are
>> solely directed at the development community.
> 
> Indeed.
> 
> 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
>    community.
> 
> 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
> community.
> 
> 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
>    public.
> 
>    - **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
> 

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


Mime
View raw message