www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Release Policy
Date Thu, 22 May 2014 19:11:55 GMT
Mark, in (b) are you talking about the 2nd paragraph of the Publication section?

I don't think that the paragraph conveys the same information as the FAQ.  IMO the FAQ here:

Which Directory For What Build?


Type	Location
Nightly Builds	people.apache.org/builds
implies that use of (the possibly somewhat obsolete considering the apache nexus instance)
people.apache.org/builds location can be used for snapshots whereas the proposed text leads
me to think that no publicly accessible snapshots should be hosted anywhere.  

Sorry, I don't have better wording to propose yet.

thanks
david jencks

On May 22, 2014, at 11:55 AM, Mark Struberg <struberg@yahoo.de> wrote:

> basically a good idea, but 
> 
> a.) why is this on legal-discuss?
> 
> b.) the section about nightly builds, snapshots and release candidates is counter productive.
We sometimes need this feedback and the ability of our users to validate bugfixes themselfs.
Just think about projects like OpenJPA and TomEE which take an hour to build and even some
special environment tweaks to build at all (e.g. increase the ulimit for open files...)
> 
> LieGrue,
> strub
> On Thursday, 22 May 2014, 20:42, Marvin Humphrey <marvin@rectangular.com> wrote:
> 
> 
> Greetings,
> 
> As discussed at ApacheCon Denver and elsewhere, I propose to migrate ASF
> Release Policy from FAQ-style to MUST/SHOULD/MAY imperative style, and
> to give Legal Affairs custodial responsibility for maintaining it.
> 
> The current FAQ-style formulation is verbose, lacks crisp boundaries,
> and is prone to policy creep as new "questions" calcify into
> requirements over time.  Its ambiguities impose a burdensome "tax" on
> volunteer resources that must be paid every time someone attempts to
> understand, explain, comply with or enforce it.  As the ASF continues to
> expand and more of our projects and contributors live at a distance from
> the Membership core where policy is forged, clarified policy
> documentation is key to the sustainability of the Foundation's culture.
> 
> A draft of the proposed policy is included below; your comments are
> solicited.  The draft was created by selecting excerpts from the
> present policy at <http://www.apache.org/dev/release.html> and then
> revising; the revision history can be viewed at
> <https://github.com/rectang/asfrelease>.
> 
> In the proposal's current form, the FAQs which compose the existing
> policy are not removed, but are instead "demoted" by dividing the page
> into two parts: "Release Policy" and "Release FAQ".  Should we arrive at
> an acceptable draft policy, the next step before publication will be to
> adapt the FAQ to eliminate redundancies.
> 
> Please note that the goal of this initiative is only to clarify policy,
> NOT TO CHANGE IT.  The proposal's more direct language may well reveal
> aspects of our policy which ought to be changed, but if the
> scope of this discussion expands to what release policy *should be*
> instead of remaining limited to what release policy *is*, our task will
> be made much more difficult.
> 
> 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 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.
> 
> 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
> package.
> 
> ## 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
> Policy](/legal/resolved).
> 
> ## 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
> 2.0](/licenses/LICENSE-2.0.txt).
> 
> 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
> policy](http://apache.org/legal/src-headers.html#notice).
> 
> 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
> header](http://www.apache.org/legal/src-headers.html#headers).
> 
> ## 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,
> `www.apache.org/dist`.
> 
> 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.
> 
> 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.
> 
> ## Policy Changes ## {#policy-changes}
> 
> Changes to Release Policy must be approved by Legal Affairs.
> 
> ## TODO
> 
> 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)
> 
> ----------------
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
> 
> 
> 


Mime
View raw message