www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Finishing release policy codification
Date Sun, 23 Aug 2015 22:12:33 GMT
On 23 August 2015 at 03:59, 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.

This is what I understood as well.

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

Agreed.

I suspect some people may read the phrase and think it means only one
or the other.
It would be helpful to clarify the intent to avoid future arguments.

>> 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".)

Oops.

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

Sorry, not really.

The definition of developer does not appear to include people who
submit bug reports.
Note also that there may be several dev lists (dev, commits, issues),
and the phrase
"a product dev list" could be taken to mean a dev list from a different product
 (which might not even be an ASF one)

Also the change to the publication rules still does not seem to allow mention
of snapshots on the developer section(s) of the website.

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

I'm not sure I agree that the policy disallows links on developer web pages
See below.

> 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 agree that allowing snapshot links on a download page would be a
policy change,
even with caveats. I just wanted to clarify this as I suspect some PMCs may not
interpret the policy this way.

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

No, I don't think it does. Not all bug reports go to "the dev list", and some
developers may only get involved via the issue tracking system.

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

IMO the intent here is to ensure "users" are not told about snapshots.

> [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.**

Again, the intent here is to avoid advertising snapshots to non-developers.
It does not say that snapshots cannot be advertised on the website.
However download pages are intended for non-developers, so should not
have such links.

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

[That needs to change as we also use Git; and some projects may build
from branches]

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

That specifically mentions "pages intended for end users", i.e it does not
preclude linkage on developer pages.

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