Release Policy

[Marvin Humphrey <ma...@rectangular.com>]

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

Re: Release Policy

[sebb <se...@gmail.com>]

On 22 May 2014 19:42, Marvin Humphrey <ma...@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.

Is there currently a requirement that VOTEing should be by majority vote?

If the PMC has agreed to an exception, it seems to me that other forms
of vote may be more sensible in certain cases.
For example, Lazy Consensus (72 hours, no negative votes) is more
appropriate for build helpers such as a shared Maven POM.

> Votes cast by PMC members are binding.

_Only_ votes cast ...

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

I think there should be a requirement to ensure that the contents of
the source package agrees with the SCM tag, as that is the only
practical way to ensure provenance of the released code.

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

I think this implies that every file in the source release must be
traceable back to a file in the SCM tag.

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

This is a bit restrictive - frequently the dist directory contains
text files such as release notes or package descriptions.
I don't think any projects currently provide hashes or sigs for such
additional files.

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

[Could note that this occurs automatically as part of a cron job]

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

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

Re: Release Policy

[Alex Harui <ah...@adobe.com>]

Hi Marvin,

Thanks and best wishes on taking on this effort.  IMO, this is important
enough that you should probably cross-post to general@incubator and other
public apache-wide lists to end the debate on which list to use and make
sure more folks see this.

A few comments:
1) Our project's web site is also published for others not considered to
be developers.  Are web-site changes considered a 'release'?

2) I agree with others who pointed out that in JIRA and on the users@
list, we should be allowed to instruct folks to try a release candidate or
nightly build to verify their problem is fixed.  Maybe there is some
standard text that can serve as a disclaimer that just accompany any
invitation to use a non-release build.

3) It is nice to see (and a bit surprising) that each vote does not have
to take 72 hours.  I'm pretty sure Flex will stop waiting that long,
especially for the 3rd and 4th release candidates that have relatively few
changes from the first release candidates.

-Alex

On 5/22/14 11:42 AM, "Marvin Humphrey" <ma...@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
>


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

Re: Release Policy

[David Jencks <da...@yahoo.com>]

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 <st...@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 <ma...@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
> 
> 
> 

Re: Ability to communicate on unreleased code

[Ross Gardler <rg...@opendirective.com>]

Personally I think your case is fine. You are making it available via SVN
and making it clear it is not a release. You can't control what others say,
you can only control what the ASF says. That's all we should care about.

I think the confusion is the word "developer", as we've seen in this thread
it is a word that can be interpreted differently. For me we should talk
about distribution mechanisms not who is encouraged to use it.

It's a release of it is made available to even the casual observer who
fires not have access to ASF resources and thus clear documentation about
the status.

It's difficult to draw a sensible line.

Ross


On Sat, May 24, 2014 at 2:14 AM, Richard Eckart de Castilho
<re...@apache.org>wrote:

On 22.05.2014, at 21:05, Richard Eckart de Castilho
<rec@apache.org<javascript:;>>
wrote:

> On 22.05.2014, at 20:55, Mark Struberg <struberg@yahoo.de <javascript:;>>
wrote:
>
>> 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.
>
> IMHO this fundamentally contradicts the spirit of open source development.
> In the next step, only people with an Apache account are permitted to
> access these lists, and I don't even want to fathom what might follow
> up to that...
>
> To me, this section kind of implies that the non-developer might
> expect some kind of quality even from the released and published
artifacts.
> This is not the case. Every sane every open source license contains
> a liability disclaimer (See sections 7 and 8 of the ASL).

I would like to come back to this thing here. I understand that we should
encourage non-developers to use unreleased stuff, but I feel this is not
a black/white thing. In particular I find the wording "The only people
who are supposed to know..." too hard.

But I would like to bring up a concrete case and would like your advice on
it.

There is a unreleased module of the UIMA project called "uimafit-spring".
It is a proof-of-concept implementation for combining UIMA and Spring
which is meant to serve as a basis for discussion for possible future
development. It is only available from the SVN (possibly from the
Jenkins builds).

However, this module *is* mentioned on the UIMA website (I put it there)
in order to find people who would be willing to discuss about it / work
on it. The website says [1]:

"""
uimafit-spring is an experimental module serving as a proof-of-concept for
the integration of UIMA with the Spring Framework. It is currently not
considered finished and uses invasive reflection in order to patch the UIMA
framework such that it passes all components created by UIMA through Spring
to provide for the wiring of Spring context dependencies. This module is
made available for the adventurous but currently not considered stable,
finished, or even a proper part of the package. E.g. it is not included in
the binary distribution package.
"""

I found that at least one person blogged about the module and one mentioned
it on Stack Overflow [2]. I have refrained from mentioning it myself in my
answered posted there because of the recent discussion about the policy
mentioned above.

So my questions:

1) is it valid to mention experimental/unreleased code/features on the
project website in order to attract new people?

2) is it valid to mention experimental/unreleased code/features elsewhere
(e.g. on Stack Overflow) while at the same time disclosing affiliation with
the releated Apache project (as required on Stack Overflow)?

3) is it valid to maintain dedicated developers sections on the project
website with information about the release process, experimental features,
etc. including links or information on how to find to the related resources?

If I take the policy "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.", I would answer
"No" to all of the questions above. However, I cannot imagine this should
be the intended message of the statement.

Cheers,

-- Richard

[1] http://uima.apache.org/uimafit.html#Modules
[2]
http://stackoverflow.com/questions/23828168/want-to-use-value-reading-the-properties-from-property-file-in-uima-framework/23842733#23842733
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org <javascript:;>
For additional commands, e-mail: legal-discuss-help@apache.org<javascript:;>



-- 
Sent from MetroMail

Ability to communicate on unreleased code

[Richard Eckart de Castilho <re...@apache.org>]

On 22.05.2014, at 21:05, Richard Eckart de Castilho <re...@apache.org> wrote:

> On 22.05.2014, at 20:55, Mark Struberg <st...@yahoo.de> wrote:
> 
>> 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.
> 
> IMHO this fundamentally contradicts the spirit of open source development.
> In the next step, only people with an Apache account are permitted to
> access these lists, and I don't even want to fathom what might follow
> up to that...
> 
> To me, this section kind of implies that the non-developer might
> expect some kind of quality even from the released and published artifacts.
> This is not the case. Every sane every open source license contains
> a liability disclaimer (See sections 7 and 8 of the ASL).

I would like to come back to this thing here. I understand that we should
encourage non-developers to use unreleased stuff, but I feel this is not
a black/white thing. In particular I find the wording "The only people
who are supposed to know..." too hard.

But I would like to bring up a concrete case and would like your advice on it.

There is a unreleased module of the UIMA project called "uimafit-spring".
It is a proof-of-concept implementation for combining UIMA and Spring
which is meant to serve as a basis for discussion for possible future
development. It is only available from the SVN (possibly from the
Jenkins builds).

However, this module *is* mentioned on the UIMA website (I put it there)
in order to find people who would be willing to discuss about it / work
on it. The website says [1]:

"""
uimafit-spring is an experimental module serving as a proof-of-concept for the integration of UIMA with the Spring Framework. It is currently not considered finished and uses invasive reflection in order to patch the UIMA framework such that it passes all components created by UIMA through Spring to provide for the wiring of Spring context dependencies. This module is made available for the adventurous but currently not considered stable, finished, or even a proper part of the package. E.g. it is not included in the binary distribution package.
"""

I found that at least one person blogged about the module and one mentioned
it on Stack Overflow [2]. I have refrained from mentioning it myself in my
answered posted there because of the recent discussion about the policy
mentioned above.

So my questions:

1) is it valid to mention experimental/unreleased code/features on the project website in order to attract new people?

2) is it valid to mention experimental/unreleased code/features elsewhere (e.g. on Stack Overflow) while at the same time disclosing affiliation with the releated Apache project (as required on Stack Overflow)?

3) is it valid to maintain dedicated developers sections on the project website with information about the release process, experimental features, etc. including links or information on how to find to the related resources?

If I take the policy "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.", I would answer "No" to all of the questions above. However, I cannot imagine this should be the intended message of the statement.

Cheers,

-- Richard

[1] http://uima.apache.org/uimafit.html#Modules
[2] http://stackoverflow.com/questions/23828168/want-to-use-value-reading-the-properties-from-property-file-in-uima-framework/23842733#23842733
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

Re: Release Policy

[Richard Eckart de Castilho <re...@apache.org>]

On 22.05.2014, at 20:55, Mark Struberg <st...@yahoo.de> wrote:

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

IMHO this fundamentally contradicts the spirit of open source development.
In the next step, only people with an Apache account are permitted to
access these lists, and I don't even want to fathom what might follow
up to that...

To me, this section kind of implies that the non-developer might
expect some kind of quality even from the released and published artifacts.
This is not the case. Every sane every open source license contains
a liability disclaimer (See sections 7 and 8 of the ASL).

Just my 10 ct,

-- Richard


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

Re: Release Policy

[Brian LeRoux <b...@brian.io>]

Also..

https://github.com/apache/httpd/releases
On May 23, 2014 10:36 AM, "Jim Jagielski" <ji...@jagunet.com> wrote:

> Look at the license. The license applies to the work.
> Is a file in a vcs somewhere a "work"? For some entities,
> like various Github projects, which muddy the whole
> concepts around release, distribution, etc... then
> the simply placement of a file on a public repo may
> be enough, for the owner/holder, to comprise a "release"
> in sufficient amount to have the license apply.
>
> On May 23, 2014, at 7:53 AM, Richard Eckart de Castilho <re...@apache.org>
> wrote:
>
> > On 23.05.2014, at 13:49, Jim Jagielski <ji...@jaguNET.com> wrote:
> >
> >> On May 22, 2014, at 5:04 PM, Mark Struberg <st...@yahoo.de> wrote:
> >>
> >>>> I disagree. One of the primary reasons for the release policy being
> >>>> defined as it is is to provide a degree of legal protection to the
> >>>> release managers.
> >>>
> >>> Oki this is a part which we can discuss on the legal list. But the
> point already got covered and answered dozens of times imo. The answer is
> that the ALv2 protects the foundation and also the release manager already
> for all bona fides cases. End of story.
> >>>
> >>
> >> Licenses take effect when source is *released* (distributed or
> >> redistributed). So it makes sense to define what a release *is*.
> >
> > Does that imply that code that somebody copies from a version
> > control system but that does not end up in a final release artifact
> > is not covered by the ASL?
> >
> > Is it illegal to obtain unreleased code that is clearly marked as
> > being under the ASL and to use it elsewhere (assuming that the
> > rules of the ASL are obeyed)?
> >
> > Cheers,
> >
> > -- Richard
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>

Re: Release Policy

[Jim Jagielski <ji...@jaguNET.com>]

Look at the license. The license applies to the work.
Is a file in a vcs somewhere a "work"? For some entities,
like various Github projects, which muddy the whole
concepts around release, distribution, etc... then
the simply placement of a file on a public repo may
be enough, for the owner/holder, to comprise a "release"
in sufficient amount to have the license apply.

On May 23, 2014, at 7:53 AM, Richard Eckart de Castilho <re...@apache.org> wrote:

> On 23.05.2014, at 13:49, Jim Jagielski <ji...@jaguNET.com> wrote:
> 
>> On May 22, 2014, at 5:04 PM, Mark Struberg <st...@yahoo.de> wrote:
>> 
>>>> I disagree. One of the primary reasons for the release policy being
>>>> defined as it is is to provide a degree of legal protection to the
>>>> release managers.
>>> 
>>> Oki this is a part which we can discuss on the legal list. But the point already got covered and answered dozens of times imo. The answer is that the ALv2 protects the foundation and also the release manager already for all bona fides cases. End of story. 
>>> 
>> 
>> Licenses take effect when source is *released* (distributed or
>> redistributed). So it makes sense to define what a release *is*.
> 
> Does that imply that code that somebody copies from a version
> control system but that does not end up in a final release artifact
> is not covered by the ASL? 
> 
> Is it illegal to obtain unreleased code that is clearly marked as
> being under the ASL and to use it elsewhere (assuming that the
> rules of the ASL are obeyed)?
> 
> Cheers,
> 
> -- Richard
> 
> 
> ---------------------------------------------------------------------
> 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

Re: Release Policy

[Jim Jagielski <ji...@jaguNET.com>]

It may be easier to look at code as other crafts...
Files in svn (or git or whatever) are, for lack of
a better term, works-in-progress. They are transitional
and mutable. During a release, the files are tagged, and
the files, at that time, become immutable as related to
that release. There is a 1-1 map between the file that
is released and the file that is part of the released
work (or the entire work itself).

On May 23, 2014, at 10:34 AM, Marvin Humphrey <ma...@rectangular.com> wrote:

> On Fri, May 23, 2014 at 4:53 AM, Richard Eckart de Castilho
> <re...@apache.org> wrote:
>> On 23.05.2014, at 13:49, Jim Jagielski <ji...@jaguNET.com> wrote:
>> 
>>> On May 22, 2014, at 5:04 PM, Mark Struberg <st...@yahoo.de> wrote:
>>> 
>>>>> I disagree. One of the primary reasons for the release policy being
>>>>> defined as it is is to provide a degree of legal protection to the
>>>>> release managers.
>>>> 
>>>> Oki this is a part which we can discuss on the legal list. But the point
>>>> already got covered and answered dozens of times imo. The answer is that
>>>> the ALv2 protects the foundation and also the release manager already for
>>>> all bona fides cases. End of story.
>>> 
>>> Licenses take effect when source is *released* (distributed or
>>> redistributed). So it makes sense to define what a release *is*.
>> 
>> Does that imply that code that somebody copies from a version
>> control system but that does not end up in a final release artifact
>> is not covered by the ASL?
>> 
>> Is it illegal to obtain unreleased code that is clearly marked as
>> being under the ASL and to use it elsewhere (assuming that the
>> rules of the ASL are obeyed)?
> 
> Code which is obtained from version control may not adhere to all of our
> policies.  For example, a new codebase undergoing IP clearance in the
> Incubator might have a mandatory dependency on a proprietary library.  Such a
> dependency would be have to be eliminated by the first incubating release.
> 
> While we would strive to avoid it, it is possible that for transitory periods,
> code in version control may violate licensing.  Perhaps an errant commit is
> caught right away by a PMC member reviewing the commits list; perhaps a
> problem is only detected during the additional checks performed in the run-up
> to a release vote.  Such glitches are an unavoidable consequence of our choice
> to participate in open development on the public internet despite the fact
> that copyright law is not perfectly tuned for it.
> 
> Please note that the draft proposal floats a "TODO" item regarding formalizing
> a bounded "ASF Licensing Policy" distinct from the Release Policy which
> "applies to both released and unreleased code":
> 
>    ## 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)
> 
> The phrase "both released and unreleased code" reflects my understanding of
> numerous discussions that took place on this list during 2009, where the point
> was raised that version control qualifies as a distribution and that licensing
> kicks in on distribution rather than release.  For instance:
> 
>    http://s.apache.org/7DC
> 
>    Of course it is a distribution point.  Distribution == copy to someone
>    else.  It isn't a release (an editorial decision by the ASF).
> 
>    [...]
> 
>    That does not mean we have to be perfect every second of every day.  It
>    means that we have to strive for correctness -- we must fix problems when
>    they are found, and we must not intentionally create problems with
>    licensing.  In any case, most of the copyright owners who license us code
>    are a pretty forgiving bunch (ourselves).
> 
> Marvin Humphrey
> 
> ---------------------------------------------------------------------
> 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

Re: Release Policy

[Marvin Humphrey <ma...@rectangular.com>]

On Fri, May 23, 2014 at 4:53 AM, Richard Eckart de Castilho
<re...@apache.org> wrote:
> On 23.05.2014, at 13:49, Jim Jagielski <ji...@jaguNET.com> wrote:
>
>> On May 22, 2014, at 5:04 PM, Mark Struberg <st...@yahoo.de> wrote:
>>
>>>> I disagree. One of the primary reasons for the release policy being
>>>> defined as it is is to provide a degree of legal protection to the
>>>> release managers.
>>>
>>> Oki this is a part which we can discuss on the legal list. But the point
>>> already got covered and answered dozens of times imo. The answer is that
>>> the ALv2 protects the foundation and also the release manager already for
>>> all bona fides cases. End of story.
>>
>> Licenses take effect when source is *released* (distributed or
>> redistributed). So it makes sense to define what a release *is*.
>
> Does that imply that code that somebody copies from a version
> control system but that does not end up in a final release artifact
> is not covered by the ASL?
>
> Is it illegal to obtain unreleased code that is clearly marked as
> being under the ASL and to use it elsewhere (assuming that the
> rules of the ASL are obeyed)?

Code which is obtained from version control may not adhere to all of our
policies.  For example, a new codebase undergoing IP clearance in the
Incubator might have a mandatory dependency on a proprietary library.  Such a
dependency would be have to be eliminated by the first incubating release.

While we would strive to avoid it, it is possible that for transitory periods,
code in version control may violate licensing.  Perhaps an errant commit is
caught right away by a PMC member reviewing the commits list; perhaps a
problem is only detected during the additional checks performed in the run-up
to a release vote.  Such glitches are an unavoidable consequence of our choice
to participate in open development on the public internet despite the fact
that copyright law is not perfectly tuned for it.

Please note that the draft proposal floats a "TODO" item regarding formalizing
a bounded "ASF Licensing Policy" distinct from the Release Policy which
"applies to both released and unreleased code":

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

The phrase "both released and unreleased code" reflects my understanding of
numerous discussions that took place on this list during 2009, where the point
was raised that version control qualifies as a distribution and that licensing
kicks in on distribution rather than release.  For instance:

    http://s.apache.org/7DC

    Of course it is a distribution point.  Distribution == copy to someone
    else.  It isn't a release (an editorial decision by the ASF).

    [...]

    That does not mean we have to be perfect every second of every day.  It
    means that we have to strive for correctness -- we must fix problems when
    they are found, and we must not intentionally create problems with
    licensing.  In any case, most of the copyright owners who license us code
    are a pretty forgiving bunch (ourselves).

Marvin Humphrey

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

Re: Release Policy

[Mark Struberg <st...@yahoo.de>]

Well, but Richard is right. Whether a piece of work is ALv2 has nothing to do whether we release it or not.
It depends purely on the 'consensus' aspects. If an author is knowingly and willingly wring a file under ALv2 then this is it. It doesn't even need publication.

What our release process adds is that we have a kind of QA. What if some committer adds code which is labeled as ALv2 but actually is only copied from a GPLv2 source, etc?
I'd compare it with a company which has no QA department. This is not illegal. But once a real problem arises then you are into troubles. The ASF release process helps to reduce that risk to a minimal level. 



The question I originally raised is really only if we need all this proper QA for test binaries which we make available (I even avoid to say 'publish' or 'release') for testing audience and which is pretty clearly marked as work in progress and 'use at even more own risk than our proper releases' :)


LieGrue,
strub


On Friday, 23 May 2014, 14:26, Jim Jagielski <ji...@jaguNET.com> wrote:
 

>
>
>FTR: That was tongue in cheek...
>On May 23, 2014, at 8:02 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> What is the ASL? I know of the ALv2.
>> 
>> On May 23, 2014, at 7:53 AM, Richard Eckart de Castilho <re...@apache.org> wrote:
>> 
>>> On 23.05.2014, at 13:49, Jim Jagielski <ji...@jaguNET.com> wrote:
>>> 
>>>> On May 22, 2014, at 5:04 PM, Mark Struberg <st...@yahoo.de> wrote:
>>>> 
>>>>>> I disagree. One of the primary reasons for the release policy being
>>>>>> defined as it is is to provide a degree of legal protection to the
>>>>>> release managers.
>>>>> 
>>>>> Oki this is a part which we can discuss on the legal list. But the point already got covered and answered dozens of times imo. The answer is that the ALv2 protects the foundation and also the release manager already for all bona fides cases. End of story. 
>>>>> 
>>>> 
>>>> Licenses take effect when source is *released* (distributed or
>>>> redistributed). So it makes sense to define what a release *is*.
>>> 
>>> Does that imply that code that somebody copies from a version
>>> control system but that does not end up in a final release artifact
>>> is not covered by the ASL? 
>>> 
>>> Is it illegal to obtain unreleased code that is clearly marked as
>>> being under the ASL and to use it elsewhere (assuming that the
>>> rules of the ASL are obeyed)?
>>> 
>>> Cheers,
>>> 
>>> -- Richard
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> 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
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>For additional commands, e-mail: legal-discuss-help@apache.org
>
>
>

Re: Release Policy

[Jim Jagielski <ji...@jaguNET.com>]

FTR: That was tongue in cheek...
On May 23, 2014, at 8:02 AM, Jim Jagielski <ji...@jagunet.com> wrote:

> What is the ASL? I know of the ALv2.
> 
> On May 23, 2014, at 7:53 AM, Richard Eckart de Castilho <re...@apache.org> wrote:
> 
>> On 23.05.2014, at 13:49, Jim Jagielski <ji...@jaguNET.com> wrote:
>> 
>>> On May 22, 2014, at 5:04 PM, Mark Struberg <st...@yahoo.de> wrote:
>>> 
>>>>> I disagree. One of the primary reasons for the release policy being
>>>>> defined as it is is to provide a degree of legal protection to the
>>>>> release managers.
>>>> 
>>>> Oki this is a part which we can discuss on the legal list. But the point already got covered and answered dozens of times imo. The answer is that the ALv2 protects the foundation and also the release manager already for all bona fides cases. End of story. 
>>>> 
>>> 
>>> Licenses take effect when source is *released* (distributed or
>>> redistributed). So it makes sense to define what a release *is*.
>> 
>> Does that imply that code that somebody copies from a version
>> control system but that does not end up in a final release artifact
>> is not covered by the ASL? 
>> 
>> Is it illegal to obtain unreleased code that is clearly marked as
>> being under the ASL and to use it elsewhere (assuming that the
>> rules of the ASL are obeyed)?
>> 
>> Cheers,
>> 
>> -- Richard
>> 
>> 
>> ---------------------------------------------------------------------
>> 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
> 


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

Re: Release Policy

[Richard Eckart de Castilho <re...@apache.org>]

Sorry, bad habit. I mean the ALv2.

-- Richard

Why this mistake? Probably because the version 1.1 was still
called "Apache Software License version 1.1" and the old
name is still floating around. 

On 23.05.2014, at 14:02, Jim Jagielski <ji...@jaguNET.com> wrote:

> What is the ASL? I know of the ALv2.
> 
> On May 23, 2014, at 7:53 AM, Richard Eckart de Castilho <re...@apache.org> wrote:
> 
>> On 23.05.2014, at 13:49, Jim Jagielski <ji...@jaguNET.com> wrote:
>> 
>>> On May 22, 2014, at 5:04 PM, Mark Struberg <st...@yahoo.de> wrote:
>>> 
>>>>> I disagree. One of the primary reasons for the release policy being
>>>>> defined as it is is to provide a degree of legal protection to the
>>>>> release managers.
>>>> 
>>>> Oki this is a part which we can discuss on the legal list. But the point already got covered and answered dozens of times imo. The answer is that the ALv2 protects the foundation and also the release manager already for all bona fides cases. End of story. 
>>>> 
>>> 
>>> Licenses take effect when source is *released* (distributed or
>>> redistributed). So it makes sense to define what a release *is*.
>> 
>> Does that imply that code that somebody copies from a version
>> control system but that does not end up in a final release artifact
>> is not covered by the ASL? 
>> 
>> Is it illegal to obtain unreleased code that is clearly marked as
>> being under the ASL and to use it elsewhere (assuming that the
>> rules of the ASL are obeyed)?
>> 
>> Cheers,
>> 
>> -- Richard


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

Re: Release Policy

[Jim Jagielski <ji...@jaguNET.com>]

What is the ASL? I know of the ALv2.

On May 23, 2014, at 7:53 AM, Richard Eckart de Castilho <re...@apache.org> wrote:

> On 23.05.2014, at 13:49, Jim Jagielski <ji...@jaguNET.com> wrote:
> 
>> On May 22, 2014, at 5:04 PM, Mark Struberg <st...@yahoo.de> wrote:
>> 
>>>> I disagree. One of the primary reasons for the release policy being
>>>> defined as it is is to provide a degree of legal protection to the
>>>> release managers.
>>> 
>>> Oki this is a part which we can discuss on the legal list. But the point already got covered and answered dozens of times imo. The answer is that the ALv2 protects the foundation and also the release manager already for all bona fides cases. End of story. 
>>> 
>> 
>> Licenses take effect when source is *released* (distributed or
>> redistributed). So it makes sense to define what a release *is*.
> 
> Does that imply that code that somebody copies from a version
> control system but that does not end up in a final release artifact
> is not covered by the ASL? 
> 
> Is it illegal to obtain unreleased code that is clearly marked as
> being under the ASL and to use it elsewhere (assuming that the
> rules of the ASL are obeyed)?
> 
> Cheers,
> 
> -- Richard
> 
> 
> ---------------------------------------------------------------------
> 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

Re: Release Policy

[Richard Eckart de Castilho <re...@apache.org>]

On 23.05.2014, at 13:49, Jim Jagielski <ji...@jaguNET.com> wrote:

> On May 22, 2014, at 5:04 PM, Mark Struberg <st...@yahoo.de> wrote:
> 
>>> I disagree. One of the primary reasons for the release policy being
>>> defined as it is is to provide a degree of legal protection to the
>>> release managers.
>> 
>> Oki this is a part which we can discuss on the legal list. But the point already got covered and answered dozens of times imo. The answer is that the ALv2 protects the foundation and also the release manager already for all bona fides cases. End of story. 
>> 
> 
> Licenses take effect when source is *released* (distributed or
> redistributed). So it makes sense to define what a release *is*.

Does that imply that code that somebody copies from a version
control system but that does not end up in a final release artifact
is not covered by the ASL? 

Is it illegal to obtain unreleased code that is clearly marked as
being under the ASL and to use it elsewhere (assuming that the
rules of the ASL are obeyed)?

Cheers,

-- Richard


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

Re: Release Policy

[Jim Jagielski <ji...@jaguNET.com>]

On May 22, 2014, at 5:04 PM, Mark Struberg <st...@yahoo.de> wrote:

>> I disagree. One of the primary reasons for the release policy being
>> defined as it is is to provide a degree of legal protection to the
>> release managers.
> 
> Oki this is a part which we can discuss on the legal list. But the point already got covered and answered dozens of times imo. The answer is that the ALv2 protects the foundation and also the release manager already for all bona fides cases. End of story. 
> 

Licenses take effect when source is *released* (distributed or
redistributed). So it makes sense to define what a release *is*.


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

Re: Release Policy

[Jim Jagielski <ji...@jaguNET.com>]

Not sure what you mean... A release is a legal action. It's when
the rubber hits the road, as it were. So discussing the policy
here makes sense... It's certainly more a legal issue than an infra
issue...

On May 22, 2014, at 6:11 PM, Joseph Schaefer <jo...@yahoo.com> wrote:

> Since when?  Since this month maybe, but for the past decade the board has entrusted infra with stewardship of the release policy.  After all that's why it's in /dev in the first place.  If this board is dissatisfied  with that relationship they can bloody well move the document to another part of the tree.
> 
> My two cents of course.
> Sent from my iPhone
> 
>> On May 22, 2014, at 6:05 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
>> 
>>> On 5/22/14 5:27 PM, Joseph Schaefer wrote:
>>> Mark Struberg is an army of one when it comes to release policy.
>>> Frankly the custodians of the policy are not subscribed to this list
>>> so I'm puzzled as to why it's being kicked around here.]
>> 
>> Well, while there are a number of groups of individuals on various lists who obviously have key input to any changes - even just better wording like Marvin is most excellently presenting - but fundamentally release policy changes need to be signed off by VP, Legal or by President; i.e. by an officer of the corporation who oversees our legal policies.  Thus, this *is* the right list to drive to consensus, unless VP, Legal has a specific question they need to ask counsel on *-internal@
>> 
>> This is corporate policy.  Compliance is mandatory for any Apache project - producing software product releases is our organization's primary mission.  Obviously, we have significant work to do in ensuring the policy is both clear enough to use, and with working with projects to ensure they comply (once we can present it clearly enough!), so this process will take some time.  But the final answer is not going to be a few people's IMO - it's going to be signed off by an officer of the ASF.
>> 
>> - Shane
>> 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On May 22, 2014, at 5:18 PM, Brian LeRoux <b...@brian.io> wrote:
>>>> 
>>>> 
>>>> 
>>>> "But the point already got covered and answered dozens of times
>>>> imo. The answer is that the ALv2 protects the foundation and also
>>>> the release manager already for all bona fides cases. End of
>>>> story."
>>>> 
>>>> Interesting for myself to note that it was communicated very
>>>> directly to Cordova that this *was not* the case. Votes are a
>>>> necessary component for a valid (aka legal) release. Also
>>>> interesting for me to discover in this thread that the release
>>>> policy is not adhered to by all ASF projects. We were lead to
>>>> believe the rules are immutable, all projects obey them. End of
>>>> story.
>>>> 
>>>> I am dismayed to discover this is not the case and Cordova was
>>>> singled out.
>>>> 
>>>> However, clarity here is a great starting to amending the rules,
>>>> and I recognize this effort is not forum for that. My perspective:
>>>> the vote is a SHOULD and most certainly SHA verifciation SHOULD be
>>>> the job of a computer (aka CI system) and not a human and I am very
>>>> happy to hear there is precedent for this with other projects.
>>>> 
>>>> ​
>>> 
>>> ---------------------------------------------------------------------
>>> 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
>> 
> 
> ---------------------------------------------------------------------
> 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

Re: Release Policy

[Marvin Humphrey <ma...@rectangular.com>]

On Sat, May 31, 2014 at 9:18 AM, Joseph Schaefer <jo...@yahoo.com> wrote:
> Infrastructure-dev@ would be my preference.  Thanks for respecting the
> wishes of an old saw whose worked hard to ensure sane changes to the release
> policy from an enforcement standpoint.

See you there.

[Trivial reply because the original hit DMARC and probably got sorted to most
list subscribers' spam folders.]

Marvin Humphrey

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

Re: Release Policy

[Joseph Schaefer <jo...@yahoo.com>]

Infrastructure-dev@ would be my preference.  Thanks for respecting the wishes of an old saw whose worked hard to ensure sane changes to the release policy from an enforcement standpoint.

Sent from my iPhone

> On May 30, 2014, at 11:42 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> 
>> On Thu, May 22, 2014 at 3:11 PM, Joseph Schaefer <jo...@yahoo.com> wrote:
>> Since when?  Since this month maybe, but for the past decade the board has
>> entrusted infra with stewardship of the release policy.  After all that's
>> why it's in /dev in the first place.
> 
> I was not aware that Infrastructure was tasked with stewarding the existing
> release policy page because that information was missing from the text and I
> didn't realize that Infra was accountable for all content under
> <www.apache.org/dev>.
> 
> The lack of transparency as to how Apache release policy gets evolved and the
> (seeming) lack of a specific maintainer are actually two points which the
> draft proposal attempts to rectify.  The existence of a defined steward makes
> things easier.
> 
>> If this board is dissatisfied with that relationship they can bloody well
>> move the document to another part of the tree.
> 
> The reasons I selected legal-discuss as a venue were best articulated earlier
> by Mark Thomas[1] but the issue of which committee has jurisdiction is not
> crucial.  What's truly important is settling on a finite release policy
> authoritatively defined by concrete text -- rather than a semi-solid release
> policy whose finer features are defined by Board member proclamations spread
> out over fifteen years of random email archives and whose ultimate meaning is
> undiscoverable by mere mortals.  If the Infra VP can deliver that, fine
> with me.
> 
> Discussion on the subject of policy clarification seems to have hit a lull;
> once things stay quiet for a day or two more, I'll raise the issue with Infra.
> For what it's worth, I didn't engage in the meta-debates over venue earlier
> mostly because attempting to transplant a fast-moving conversation would have
> been chaotic and futile.
> 
> Anticipating that some may favor Legal Affairs for stewardship, my response is
> that I'd prefer to hear from Infra on their own turf first.
> 
> Joe, what public list should I take this to?
> 
> Marvin Humphrey
> 
> [1] http://markmail.org/message/n2lpb4d6ve352bej
> 
> ---------------------------------------------------------------------
> 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

Re: Release Policy

[Marvin Humphrey <ma...@rectangular.com>]

On Thu, May 22, 2014 at 3:11 PM, Joseph Schaefer <jo...@yahoo.com> wrote:
> Since when?  Since this month maybe, but for the past decade the board has
> entrusted infra with stewardship of the release policy.  After all that's
> why it's in /dev in the first place.

I was not aware that Infrastructure was tasked with stewarding the existing
release policy page because that information was missing from the text and I
didn't realize that Infra was accountable for all content under
<www.apache.org/dev>.

The lack of transparency as to how Apache release policy gets evolved and the
(seeming) lack of a specific maintainer are actually two points which the
draft proposal attempts to rectify.  The existence of a defined steward makes
things easier.

> If this board is dissatisfied with that relationship they can bloody well
> move the document to another part of the tree.

The reasons I selected legal-discuss as a venue were best articulated earlier
by Mark Thomas[1] but the issue of which committee has jurisdiction is not
crucial.  What's truly important is settling on a finite release policy
authoritatively defined by concrete text -- rather than a semi-solid release
policy whose finer features are defined by Board member proclamations spread
out over fifteen years of random email archives and whose ultimate meaning is
undiscoverable by mere mortals.  If the Infra VP can deliver that, fine
with me.

Discussion on the subject of policy clarification seems to have hit a lull;
once things stay quiet for a day or two more, I'll raise the issue with Infra.
For what it's worth, I didn't engage in the meta-debates over venue earlier
mostly because attempting to transplant a fast-moving conversation would have
been chaotic and futile.

Anticipating that some may favor Legal Affairs for stewardship, my response is
that I'd prefer to hear from Infra on their own turf first.

Joe, what public list should I take this to?

Marvin Humphrey

[1] http://markmail.org/message/n2lpb4d6ve352bej

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

Re: Release Policy

[Joseph Schaefer <jo...@yahoo.com>]

Since when?  Since this month maybe, but for the past decade the board has entrusted infra with stewardship of the release policy.  After all that's why it's in /dev in the first place.  If this board is dissatisfied  with that relationship they can bloody well move the document to another part of the tree.

My two cents of course.
Sent from my iPhone

> On May 22, 2014, at 6:05 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
> 
>> On 5/22/14 5:27 PM, Joseph Schaefer wrote:
>> Mark Struberg is an army of one when it comes to release policy.
>> Frankly the custodians of the policy are not subscribed to this list
>> so I'm puzzled as to why it's being kicked around here.]
> 
> Well, while there are a number of groups of individuals on various lists who obviously have key input to any changes - even just better wording like Marvin is most excellently presenting - but fundamentally release policy changes need to be signed off by VP, Legal or by President; i.e. by an officer of the corporation who oversees our legal policies.  Thus, this *is* the right list to drive to consensus, unless VP, Legal has a specific question they need to ask counsel on *-internal@
> 
> This is corporate policy.  Compliance is mandatory for any Apache project - producing software product releases is our organization's primary mission.  Obviously, we have significant work to do in ensuring the policy is both clear enough to use, and with working with projects to ensure they comply (once we can present it clearly enough!), so this process will take some time.  But the final answer is not going to be a few people's IMO - it's going to be signed off by an officer of the ASF.
> 
> - Shane
> 
>> 
>> Sent from my iPhone
>> 
>>> On May 22, 2014, at 5:18 PM, Brian LeRoux <b...@brian.io> wrote:
>>> 
>>> 
>>> 
>>> "But the point already got covered and answered dozens of times
>>> imo. The answer is that the ALv2 protects the foundation and also
>>> the release manager already for all bona fides cases. End of
>>> story."
>>> 
>>> Interesting for myself to note that it was communicated very
>>> directly to Cordova that this *was not* the case. Votes are a
>>> necessary component for a valid (aka legal) release. Also
>>> interesting for me to discover in this thread that the release
>>> policy is not adhered to by all ASF projects. We were lead to
>>> believe the rules are immutable, all projects obey them. End of
>>> story.
>>> 
>>> I am dismayed to discover this is not the case and Cordova was
>>> singled out.
>>> 
>>> However, clarity here is a great starting to amending the rules,
>>> and I recognize this effort is not forum for that. My perspective:
>>> the vote is a SHOULD and most certainly SHA verifciation SHOULD be
>>> the job of a computer (aka CI system) and not a human and I am very
>>> happy to hear there is precedent for this with other projects.
>>> 
>>> ​
>> 
>> ---------------------------------------------------------------------
>> 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
> 

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

Re: Release Policy

[Shane Curcuru <as...@shanecurcuru.org>]

On 5/22/14 5:27 PM, Joseph Schaefer wrote:
> Mark Struberg is an army of one when it comes to release policy.
> Frankly the custodians of the policy are not subscribed to this list
> so I'm puzzled as to why it's being kicked around here.]

Well, while there are a number of groups of individuals on various lists 
who obviously have key input to any changes - even just better wording 
like Marvin is most excellently presenting - but fundamentally release 
policy changes need to be signed off by VP, Legal or by President; i.e. 
by an officer of the corporation who oversees our legal policies.  Thus, 
this *is* the right list to drive to consensus, unless VP, Legal has a 
specific question they need to ask counsel on *-internal@

This is corporate policy.  Compliance is mandatory for any Apache 
project - producing software product releases is our organization's 
primary mission.  Obviously, we have significant work to do in ensuring 
the policy is both clear enough to use, and with working with projects 
to ensure they comply (once we can present it clearly enough!), so this 
process will take some time.  But the final answer is not going to be a 
few people's IMO - it's going to be signed off by an officer of the ASF.

- Shane

>
> Sent from my iPhone
>
>> On May 22, 2014, at 5:18 PM, Brian LeRoux <b...@brian.io> wrote:
>>
>>
>>
>> "But the point already got covered and answered dozens of times
>> imo. The answer is that the ALv2 protects the foundation and also
>> the release manager already for all bona fides cases. End of
>> story."
>>
>> Interesting for myself to note that it was communicated very
>> directly to Cordova that this *was not* the case. Votes are a
>> necessary component for a valid (aka legal) release. Also
>> interesting for me to discover in this thread that the release
>> policy is not adhered to by all ASF projects. We were lead to
>> believe the rules are immutable, all projects obey them. End of
>> story.
>>
>> I am dismayed to discover this is not the case and Cordova was
>> singled out.
>>
>> However, clarity here is a great starting to amending the rules,
>> and I recognize this effort is not forum for that. My perspective:
>> the vote is a SHOULD and most certainly SHA verifciation SHOULD be
>> the job of a computer (aka CI system) and not a human and I am very
>> happy to hear there is precedent for this with other projects.
>>
>> ​
>
> ---------------------------------------------------------------------
> 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

Re: Release Policy

[Joseph Schaefer <jo...@yahoo.com>]

Mark Struberg is an army of one when it comes to release policy.  Frankly the custodians of the policy are not subscribed to this list so I'm puzzled as to why it's being kicked around here.

Sent from my iPhone

> On May 22, 2014, at 5:18 PM, Brian LeRoux <b...@brian.io> wrote:
> 
> 
> 
> "But the point already got covered and answered dozens of times imo. The answer is that the ALv2 protects the foundation and also the release manager already for all bona fides cases. End of story."
> 
> Interesting for myself to note that it was communicated very directly to Cordova that this *was not* the case. Votes are a necessary component for a valid (aka legal) release. Also interesting for me to discover in this thread that the release policy is not adhered to by all ASF projects. We were lead to believe the rules are immutable, all projects obey them. End of story. 
> 
> I am dismayed to discover this is not the case and Cordova was singled out. 
> 
> However, clarity here is a great starting to amending the rules, and I recognize this effort is not forum for that. My perspective: the vote is a SHOULD and most certainly SHA verifciation SHOULD be the job of a computer (aka CI system) and not a human and I am very happy to hear there is precedent for this with other projects. 
> 
> ​

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

Re: Release Policy

[Brian LeRoux <b...@brian.io>]

@mark Of course. This is what we do as committers. Daily! And yes, we use
Rat too. :)
On May 23, 2014 10:23 AM, "Mark Struberg" <st...@yahoo.de> wrote:

> SOME parts could be done via automated scripts. Like checking whether the
> key is correct.
> Other things like checking if a file is just not only labeled as ALv2 but
> really IS it (and not just copied and illegally 're-licensed') and various
> other things can only be checked by humans. Most times such things
> automatically already pop up because PMCs *should* also be subscribed to
> commits@xxx.a.o of their projects. But other things like checking
> dependencies and proper NOTICE files are really up for humans to visually
> verify the content.
>
> The creadur project [1] (formerly known as 'rat' - Apache Release Audit
> Tool) already helps with a few automated tasks if you have an ant or maven
> build. This project could btw need some additional helping hands...
>
> LieGrue,
> strub
>
> [1] http://creadur.apache.org/
>   On Friday, 23 May 2014, 17:02, Brian LeRoux <b...@brian.io> wrote:
>
>
>
> @mark agree, there are many layers to the stated legal perception and
> indeed most other OSS projects do not require a VOTE. It was communicated
> to me that the VOTE specifically mitigated risk to the releasing individual
> (publishing artifacts to ./dist). This, and human error, are mitigated by
> not using humans to perform those actions susceptible to human error. That
> is the point of a CI system and automated builds. All the actions of a
> release could be done by a machine and ensuring the policy will allow that
> is what I'm looking for.
>
>
> On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de> wrote:
>
> Brian, we only specifically talked about whether we should be allowed to
> give_intermediate_ build artifacts like nightly builds, etc to interested
> people. I personally find it a bit too restrictive to not allow to publish
> those for user testing. We (the foundation) already do this via our
> snapshots maven repos...
>
> And there are also different layers of 'legal'. There is no law in the US
> nor otherwhere in the world who requires a VOTE before an opensource
> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
>
> BUT: it is an ASF policy and thus binding for all our projects to VOTE on
> releases.
> And it is a really good one as it increases the technical and legal
> quality of our products! It's really a good thing to have 10+ people
> looking at a release and e.g. discovering that a file has the wrong license
> and should get removed again for example. And of course it helps reducing
> the risk from getting sued because we obviously try to minimize human
> errors.
>
> @Shane I'm not sure how many ASF members are subscribed to the legal list,
> maybe it is enough if we just rise awareness.
>
> LieGrue,
> strub
>
>
>   On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
>
>
>
>
>
> "But the point already got covered and answered dozens of times imo. The
> answer is that the ALv2 protects the foundation and also the release
> manager already for all bona fides cases. End of story."
>
>
> Interesting for myself to note that it was communicated very directly to
> Cordova that this *was not* the case. Votes are a necessary component for a
> valid (aka legal) release. Also interesting for me to discover in this
> thread that the release policy is not adhered to by all ASF projects. We
> were lead to believe the rules are immutable, all projects obey them. End
> of story.
>
> I am dismayed to discover this is not the case and Cordova was singled
> out.
>
> However, clarity here is a great starting to amending the rules, and I
> recognize this effort is not forum for that. My perspective: the vote is a
> SHOULD and most certainly SHA verifciation SHOULD be the job of a computer
> (aka CI system) and not a human and I am very happy to hear there is
> precedent for this with other projects.
>
>
> ​
>
>
>
>
>
>

Re: Release Policy

[Mark Struberg <st...@yahoo.de>]

SOME parts could be done via automated scripts. Like checking whether the key is correct. 

Other things like checking if a file is just not only labeled as ALv2 but really IS it (and not just copied and illegally 're-licensed') and various other things can only be checked by humans. Most times such things automatically already pop up because PMCs *should* also be subscribed to commits@xxx.a.o of their projects. But other things like checking dependencies and proper NOTICE files are really up for humans to visually verify the content.


The creadur project [1] (formerly known as 'rat' - Apache Release Audit Tool) already helps with a few automated tasks if you have an ant or maven build. This project could btw need some additional helping hands...


LieGrue,
strub


[1] http://creadur.apache.org/

On Friday, 23 May 2014, 17:02, Brian LeRoux <b...@brian.io> wrote:
 

>
>
>@mark agree, there are many layers to the stated legal perception and indeed most other OSS projects do not require a VOTE. It was communicated to me that the VOTE specifically mitigated risk to the releasing individual (publishing artifacts to ./dist). This, and human error, are mitigated by not using humans to perform those actions susceptible to human error. That is the point of a CI system and automated builds. All the actions of a release could be done by a machine and ensuring the policy will allow that is what I'm looking for. 
>
>
>
>
>On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de> wrote:
>
>Brian, we only specifically talked about whether we should be allowed to give_intermediate_ build artifacts like nightly builds, etc to interested people. I personally find it a bit too restrictive to not allow to publish those for user testing. We (the foundation) already do this via our snapshots maven repos...
>>
>>
>>
>>And there are also different layers of 'legal'. There is no law in the US nor otherwhere in the world who requires a VOTE before an opensource release. JBoss doesn't do it, Eclipse doesn't do it, etc. 
>>
>>
>>
>>BUT: it is an ASF policy and thus binding for all our projects to VOTE on releases. 
>>And it is a really good one as it increases the technical and legal quality of our products! It's really a good thing to have 10+ people looking at a release and e.g. discovering that a file has the wrong license and should get removed again for example. And of course it helps reducing the risk from getting sued because we obviously try to minimize human errors. 
>>
>>
>>@Shane I'm not sure how many ASF members are subscribed to the legal list, maybe it is enough if we just rise awareness.
>>
>>
>>LieGrue,
>>strub
>>
>>
>>
>>
>>
>>On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
>> 
>>
>>>
>>>
>>>
>>>
>>>"But the
 point already got covered and answered dozens of times imo. The answer 
is that the ALv2 protects the foundation and also the release manager 
already for all bona fides cases. End of story."
>>>
>>>Interesting for myself to note that it was communicated very directly to Cordova that this *was not* the case. Votes are a necessary component for a valid (aka legal) release. Also interesting for me to discover in this thread that the release policy is not adhered to by all ASF projects. We were lead to believe the rules are immutable, all projects obey them. End of story. 
>>>
>>>I am dismayed to discover this is not the case and Cordova was singled out. 
>>>
>>>However, clarity here is a great starting to amending the rules, and I recognize this effort is not forum for that. My perspective: the vote is a SHOULD and most certainly SHA verifciation SHOULD be the job of a computer (aka CI system) and not a human and I am very happy to hear there is precedent for this with other projects. 
>>>
>>>
>>>​
>>>
>>>
>
>
>

Re: Release Policy

[sebb <se...@gmail.com>]

On 23 May 2014 16:33, Brian LeRoux <b...@brian.io> wrote:
> C'mon Sebb. This is circular false logic.

The fact is that automated systems can have subtle bugs that can lurk
unseen for a long while.

There was just such an example in the Maven project about a year ago.
It had been using the standard packaging methods and no-one had
checked that the release contents actually agreed with the tags. I was
repeatedly told that it was not possible for any discrepancies to
occur.

There was a slight bug in a test script which caused a spurious file
to be included in the source release archive.
Luckily the additional file was harmless, but the point is that it is
important to be able to run an _independent_ check that the source
archive agrees with the tag. Both to ensure that spurious files are
not accidentally included and to ensure that required files are not
accidentally omitted.

> On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com> wrote:
>>
>> On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
>> > @mark agree, there are many layers to the stated legal perception and
>> > indeed
>> > most other OSS projects do not require a VOTE. It was communicated to me
>> > that the VOTE specifically mitigated risk to the releasing individual
>> > (publishing artifacts to ./dist). This, and human error, are mitigated
>> > by
>> > not using humans to perform those actions susceptible to human error.
>> > That
>> > is the point of a CI system and automated builds. All the actions of a
>> > release could be done by a machine and ensuring the policy will allow
>> > that
>> > is what I'm looking for.
>>
>> However, the CI and automated build systems are created by fallible
>> humans.
>>
>> This is why it is important to ensure that the release vote contains
>> sufficient details for an independent check of the source release
>> contents against the SCM tag.
>>
>> >
>> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de>
>> > wrote:
>> >>
>> >> Brian, we only specifically talked about whether we should be allowed
>> >> to
>> >> give_intermediate_ build artifacts like nightly builds, etc to
>> >> interested
>> >> people. I personally find it a bit too restrictive to not allow to
>> >> publish
>> >> those for user testing. We (the foundation) already do this via our
>> >> snapshots maven repos...
>> >>
>> >> And there are also different layers of 'legal'. There is no law in the
>> >> US
>> >> nor otherwhere in the world who requires a VOTE before an opensource
>> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
>> >>
>> >> BUT: it is an ASF policy and thus binding for all our projects to VOTE
>> >> on
>> >> releases.
>> >> And it is a really good one as it increases the technical and legal
>> >> quality of our products! It's really a good thing to have 10+ people
>> >> looking
>> >> at a release and e.g. discovering that a file has the wrong license and
>> >> should get removed again for example. And of course it helps reducing
>> >> the
>> >> risk from getting sued because we obviously try to minimize human
>> >> errors.
>> >>
>> >> @Shane I'm not sure how many ASF members are subscribed to the legal
>> >> list,
>> >> maybe it is enough if we just rise awareness.
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >>
>> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> "But the point already got covered and answered dozens of times imo.
>> >> The
>> >> answer is that the ALv2 protects the foundation and also the release
>> >> manager
>> >> already for all bona fides cases. End of story."
>> >>
>> >>
>> >> Interesting for myself to note that it was communicated very directly
>> >> to
>> >> Cordova that this *was not* the case. Votes are a necessary component
>> >> for a
>> >> valid (aka legal) release. Also interesting for me to discover in this
>> >> thread that the release policy is not adhered to by all ASF projects.
>> >> We
>> >> were lead to believe the rules are immutable, all projects obey them.
>> >> End of
>> >> story.
>> >>
>> >> I am dismayed to discover this is not the case and Cordova was singled
>> >> out.
>> >>
>> >> However, clarity here is a great starting to amending the rules, and I
>> >> recognize this effort is not forum for that. My perspective: the vote
>> >> is a
>> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
>> >> computer
>> >> (aka CI system) and not a human and I am very happy to hear there is
>> >> precedent for this with other projects.
>> >>
>> >>
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> 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

Re: Release Policy

[Mark Thomas <ma...@apache.org>]

On 23/05/2014 19:34, Alex Harui wrote:
> Is such a petition a simple email to board@ or a resolution for a board
> meeting?  How is it approved, by lazy?

I'm not aware of any precedents for a project being granted a general
exception.

All the exceptions I am aware of involved critical security issues and
while the vote might have been short (I've done releases with a voting
period a just a few hours in the past), there was always plenty of
(possibly PMC private) notice that the vote was coming so the PMC
members as a whole were aware and had an opportunity to voice objections
to the voting period.

I'd suggest starting with an e-mail to board@ and see what the board
advises.

I think there probably is a more general case for shorter voting periods
but I also have concerns about the process being abused. How to balance
those conflicting requirements and do so with a policy that is clear and
unambiguous is something I don't see an immediate solution to. Hopefully
others will have better ideas than mine.

Mark


> 
> Thanks,
> -Alex
> 
> On 5/23/14 11:30 AM, "Marvin Humphrey" <ma...@rectangular.com> wrote:
> 
>> On Fri, May 23, 2014 at 11:28 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>>> I, for one, would definitely prefer to not wait 72 hours for every
>>> release
>>> candidate.
>>
>> Please petition the Board.
>>
>> Marvin Humphrey
>>
>> ---------------------------------------------------------------------
>> 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
> 


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

Re: Release Policy

[Alex Harui <ah...@adobe.com>]

Is such a petition a simple email to board@ or a resolution for a board
meeting?  How is it approved, by lazy?

Thanks,
-Alex

On 5/23/14 11:30 AM, "Marvin Humphrey" <ma...@rectangular.com> wrote:

>On Fri, May 23, 2014 at 11:28 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> I, for one, would definitely prefer to not wait 72 hours for every
>>release
>> candidate.
>
>Please petition the Board.
>
>Marvin Humphrey
>
>---------------------------------------------------------------------
>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

Re: Release Policy

[Marvin Humphrey <ma...@rectangular.com>]

On Fri, May 23, 2014 at 11:28 AM, Alex Harui <ah...@adobe.com> wrote:

> I, for one, would definitely prefer to not wait 72 hours for every release
> candidate.

Please petition the Board.

Marvin Humphrey

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

Re: Release Policy

[Alex Harui <ah...@adobe.com>]

I understand the principle behind the 72 hours (or at least, I understand
that it exists to give volunteers more time to find room in their schedule
to test the release).

However, for all 10 or so Flex releases so far involving probably 50
release candidates, there has been almost no additional information gained
after about 24 hours.  I think that is because beyond the half-dozen or so
developers who have actively worked on a particular release, the Apache
Flex community is not inclined to take the time to test source packages,
especially since they don't trust that any particular RC has a higher
likelihood of being the actual release.  They'd rather try the binary
package after it is released, report bugs, and wait for the next one.
Twice now, we've learned about a critical bug shortly after 72 hours
passed and the release was finally announced and had to ship another
release right away and the total time to satisfaction for that customer
was actually delayed by the 72 hour rule.  We had our 3 votes right away,
and then had to wait another 60 hours or so.

I, for one, would definitely prefer to not wait 72 hours for every release
candidate.

Thanks,
-Alex


On 5/23/14 10:59 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:

>+1... We want to give people a chance to test and
>vote.
>
>On May 23, 2014, at 1:34 PM, Mark Struberg <st...@yahoo.de> wrote:
>
>> imo we should keep the 72h as mandatory .
>> If 3 PMC members vote +1 in the first hour then the others still have
>>71h left to -1 and thus decline the release.
>> 
>> I could only think about exceptions for e.g. 0-day exploits if more
>>than half of the PMC members did cast a +1 already.
>> But this rarely happens and users are free (and even welcomed!) to
>>'test' our staged releases.
>> 
>> LieGrue,
>> strub
>> 
>> On Friday, 23 May 2014, 18:56, Alex Harui <ah...@adobe.com> wrote:
>> 
>> 
>> This current proposal no longer requires 72 hour voting.  To me, this
>> means that we could eventually automate releasing to the point where the
>> CI prepares a set of packages with MD5 sums separately prepares a report
>> of all new files and all files with changes to the headers.
>> 
>> The RM then runs another tool that downloads the packages, verifies the
>> MD5, signs with the PGP key (yes, the RM has to type in their password)
>> and uploads it to the RC server.
>> 
>> Then three folks run another tool that downloads the packages, verifies
>> signatures, expands the source package, runs RAT, downloads an SCM tag,
>> compares the source against the tag, runs the default ant or maven
>>target,
>> and prepares a report with the LICENSE and NOTICE files and headers of
>>new
>> files and changed headers and RAT output.
>> 
>> As soon as three folks vote +1 and there are not more -1's, another tool
>> is run to push it to the release server.
>> 
>> Would this meet requirements and be acceptable?
>> 
>> What if a machine did the downloading of packages, signature
>>verification,
>> RAT, SCM compare and build so the voters only need to review a report
>> before voting.  Would that also meet requirements and be acceptable?
>> 
>> Thanks,
>> -Alex
>> 
>> On 5/23/14 8:43 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
>> 
>> >People perform releases. They can use whatever tools
>> >they want, but at the end, the only validation check
>> >that really matters are those PMC members who test,
>> >validate and +1 the release.
>> >
>> >For example, let's say that there is a codebase that
>> >doesn't pass some test, but get's the required 3 +1s
>> >for release and the RM doesn't pull it. Even though
>> >according to the CI (or whatever) it's "not a release"
>> >(it failed), as far as the PMC and the ASF is concerned,
>> >it IS a release.
>> >
>> >Conversely, no matter what a CI may test, package and
>> >drop off somewhere, if it's not voted on, it's not
>> >a release.
>> >
>> >On May 23, 2014, at 11:33 AM, Brian LeRoux <b...@brian.io> wrote:
>> >
>> >> C'mon Sebb. This is circular false logic.
>> >> 
>> >> On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com> wrote:
>> >> On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
>> >> > @mark agree, there are many layers to the stated legal perception
>>and
>> >>indeed
>> >> > most other OSS projects do not require a VOTE. It was communicated
>>to
>> >>me
>> >> > that the VOTE specifically mitigated risk to the releasing
>>individual
>> >> > (publishing artifacts to ./dist). This, and human error, are
>> >>mitigated by
>> >> > not using humans to perform those actions susceptible to human
>>error.
>> >>That
>> >> > is the point of a CI system and automated builds. All the actions
>>of a
>> >> > release could be done by a machine and ensuring the policy will
>>allow
>> >>that
>> >> > is what I'm looking for.
>> >> 
>> >> However, the CI and automated build systems are created by fallible
>> >>humans.
>> >> 
>> >> This is why it is important to ensure that the release vote contains
>> >> sufficient details for an independent check of the source release
>> >> contents against the SCM tag.
>> >> 
>> >> >
>> >> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de>
>> >>wrote:
>> >> >>
>> >> >> Brian, we only specifically talked about whether we should be
>> >>allowed to
>> >> >> give_intermediate_ build artifacts like nightly builds, etc to
>> >>interested
>> >> >> people. I personally find it a bit too restrictive to not allow to
>> >>publish
>> >> >> those for user testing. We (the foundation) already do this via
>>our
>> >> >> snapshots maven repos...
>> >> >>
>> >> >> And there are also different layers of 'legal'. There is no law in
>> >>the US
>> >> >> nor otherwhere in the world who requires a VOTE before an
>>opensource
>> >> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
>> >> >>
>> >> >> BUT: it is an ASF policy and thus binding for all our projects to
>> >>VOTE on
>> >> >> releases.
>> >> >> And it is a really good one as it increases the technical and
>>legal
>> >> >> quality of our products! It's really a good thing to have 10+
>>people
>> >>looking
>> >> >> at a release and e.g. discovering that a file has the wrong
>>license
>> >>and
>> >> >> should get removed again for example. And of course it helps
>> >>reducing the
>> >> >> risk from getting sued because we obviously try to minimize human
>> >>errors.
>> >> >>
>> >> >> @Shane I'm not sure how many ASF members are subscribed to the
>>legal
>> >>list,
>> >> >> maybe it is enough if we just rise awareness.
>> >> >>
>> >> >> LieGrue,
>> >> >> strub
>> >> >>
>> >> >>
>> >> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> "But the point already got covered and answered dozens of times
>>imo.
>> >>The
>> >> >> answer is that the ALv2 protects the foundation and also the
>>release
>> >>manager
>> >> >> already for all bona fides cases. End of story."
>> >> >>
>> >> >>
>> >> >> Interesting for myself to note that it was communicated very
>> >>directly to
>> >> >> Cordova that this *was not* the case. Votes are a necessary
>> >>component for a
>> >> >> valid (aka legal) release. Also interesting for me to discover in
>> >>this
>> >> >> thread that the release policy is not adhered to by all ASF
>> >>projects. We
>> >> >> were lead to believe the rules are immutable, all projects obey
>> >>them. End of
>> >> >> story.
>> >> >>
>> >> >> I am dismayed to discover this is not the case and Cordova was
>> >>singled
>> >> >> out.
>> >> >>
>> >> >> However, clarity here is a great starting to amending the rules,
>>and
>> >>I
>> >> >> recognize this effort is not forum for that. My perspective: the
>> >>vote is a
>> >> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
>> >>computer
>> >> >> (aka CI system) and not a human and I am very happy to hear there
>>is
>> >> >> precedent for this with other projects.
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> 
>> >> ---------------------------------------------------------------------
>> >> 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
>> >
>> 
>> 
>> ---------------------------------------------------------------------
>> 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
>


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

Re: Release Policy

[Jim Jagielski <ji...@jaguNET.com>]

+1... We want to give people a chance to test and
vote.

On May 23, 2014, at 1:34 PM, Mark Struberg <st...@yahoo.de> wrote:

> imo we should keep the 72h as mandatory . 
> If 3 PMC members vote +1 in the first hour then the others still have 71h left to -1 and thus decline the release.
> 
> I could only think about exceptions for e.g. 0-day exploits if more than half of the PMC members did cast a +1 already.
> But this rarely happens and users are free (and even welcomed!) to 'test' our staged releases. 
> 
> LieGrue,
> strub
> 
> On Friday, 23 May 2014, 18:56, Alex Harui <ah...@adobe.com> wrote:
> 
> 
> This current proposal no longer requires 72 hour voting.  To me, this
> means that we could eventually automate releasing to the point where the
> CI prepares a set of packages with MD5 sums separately prepares a report
> of all new files and all files with changes to the headers.
> 
> The RM then runs another tool that downloads the packages, verifies the
> MD5, signs with the PGP key (yes, the RM has to type in their password)
> and uploads it to the RC server.
> 
> Then three folks run another tool that downloads the packages, verifies
> signatures, expands the source package, runs RAT, downloads an SCM tag,
> compares the source against the tag, runs the default ant or maven target,
> and prepares a report with the LICENSE and NOTICE files and headers of new
> files and changed headers and RAT output.
> 
> As soon as three folks vote +1 and there are not more -1's, another tool
> is run to push it to the release server.
> 
> Would this meet requirements and be acceptable?
> 
> What if a machine did the downloading of packages, signature verification,
> RAT, SCM compare and build so the voters only need to review a report
> before voting.  Would that also meet requirements and be acceptable?
> 
> Thanks,
> -Alex
> 
> On 5/23/14 8:43 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
> 
> >People perform releases. They can use whatever tools
> >they want, but at the end, the only validation check
> >that really matters are those PMC members who test,
> >validate and +1 the release.
> >
> >For example, let's say that there is a codebase that
> >doesn't pass some test, but get's the required 3 +1s
> >for release and the RM doesn't pull it. Even though
> >according to the CI (or whatever) it's "not a release"
> >(it failed), as far as the PMC and the ASF is concerned,
> >it IS a release.
> >
> >Conversely, no matter what a CI may test, package and
> >drop off somewhere, if it's not voted on, it's not
> >a release.
> >
> >On May 23, 2014, at 11:33 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> C'mon Sebb. This is circular false logic.
> >> 
> >> On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com> wrote:
> >> On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
> >> > @mark agree, there are many layers to the stated legal perception and
> >>indeed
> >> > most other OSS projects do not require a VOTE. It was communicated to
> >>me
> >> > that the VOTE specifically mitigated risk to the releasing individual
> >> > (publishing artifacts to ./dist). This, and human error, are
> >>mitigated by
> >> > not using humans to perform those actions susceptible to human error.
> >>That
> >> > is the point of a CI system and automated builds. All the actions of a
> >> > release could be done by a machine and ensuring the policy will allow
> >>that
> >> > is what I'm looking for.
> >> 
> >> However, the CI and automated build systems are created by fallible
> >>humans.
> >> 
> >> This is why it is important to ensure that the release vote contains
> >> sufficient details for an independent check of the source release
> >> contents against the SCM tag.
> >> 
> >> >
> >> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de>
> >>wrote:
> >> >>
> >> >> Brian, we only specifically talked about whether we should be
> >>allowed to
> >> >> give_intermediate_ build artifacts like nightly builds, etc to
> >>interested
> >> >> people. I personally find it a bit too restrictive to not allow to
> >>publish
> >> >> those for user testing. We (the foundation) already do this via our
> >> >> snapshots maven repos...
> >> >>
> >> >> And there are also different layers of 'legal'. There is no law in
> >>the US
> >> >> nor otherwhere in the world who requires a VOTE before an opensource
> >> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
> >> >>
> >> >> BUT: it is an ASF policy and thus binding for all our projects to
> >>VOTE on
> >> >> releases.
> >> >> And it is a really good one as it increases the technical and legal
> >> >> quality of our products! It's really a good thing to have 10+ people
> >>looking
> >> >> at a release and e.g. discovering that a file has the wrong license
> >>and
> >> >> should get removed again for example. And of course it helps
> >>reducing the
> >> >> risk from getting sued because we obviously try to minimize human
> >>errors.
> >> >>
> >> >> @Shane I'm not sure how many ASF members are subscribed to the legal
> >>list,
> >> >> maybe it is enough if we just rise awareness.
> >> >>
> >> >> LieGrue,
> >> >> strub
> >> >>
> >> >>
> >> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> "But the point already got covered and answered dozens of times imo.
> >>The
> >> >> answer is that the ALv2 protects the foundation and also the release
> >>manager
> >> >> already for all bona fides cases. End of story."
> >> >>
> >> >>
> >> >> Interesting for myself to note that it was communicated very
> >>directly to
> >> >> Cordova that this *was not* the case. Votes are a necessary
> >>component for a
> >> >> valid (aka legal) release. Also interesting for me to discover in
> >>this
> >> >> thread that the release policy is not adhered to by all ASF
> >>projects. We
> >> >> were lead to believe the rules are immutable, all projects obey
> >>them. End of
> >> >> story.
> >> >>
> >> >> I am dismayed to discover this is not the case and Cordova was
> >>singled
> >> >> out.
> >> >>
> >> >> However, clarity here is a great starting to amending the rules, and
> >>I
> >> >> recognize this effort is not forum for that. My perspective: the
> >>vote is a
> >> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
> >>computer
> >> >> (aka CI system) and not a human and I am very happy to hear there is
> >> >> precedent for this with other projects.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> 
> >> ---------------------------------------------------------------------
> >> 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
> >
> 
> 
> ---------------------------------------------------------------------
> 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

Re: Release Policy

[Mark Struberg <st...@yahoo.de>]

imo we should keep the 72h as mandatory . 

If 3 PMC members vote +1 in the first hour then the others still have 71h left to -1 and thus decline the release.

I could only think about exceptions for e.g. 0-day exploits if more than half of the PMC members did cast a +1 already.
But this rarely happens and users are free (and even welcomed!) to 'test' our staged releases. 


LieGrue,
strub


On Friday, 23 May 2014, 18:56, Alex Harui <ah...@adobe.com> wrote:
 

>
>
>This current proposal no longer requires 72 hour voting.  To me, this
>means that we could eventually automate releasing to the point where the
>CI prepares a set of packages with MD5 sums separately prepares a report
>of all new files and all files with changes to the headers.
>
>The RM then runs another tool that downloads the packages, verifies the
>MD5, signs with the PGP key (yes, the RM has to type in their password)
>and uploads it to the RC server.
>
>Then three folks run another tool that downloads the packages, verifies
>signatures, expands the source package, runs RAT, downloads an SCM tag,
>compares the source against the tag, runs the default ant or maven target,
>and prepares a report with the LICENSE and NOTICE files and headers of new
>files and changed headers and RAT output.
>
>As soon as three folks vote +1 and there are not more -1's, another tool
>is run to push it to the release server.
>
>Would this meet requirements and be acceptable?
>
>What if a machine did the downloading of packages, signature verification,
>RAT, SCM compare and build so the voters only need to review a report
>before voting.  Would that also meet requirements and be acceptable?
>
>Thanks,
>-Alex
>
>On 5/23/14 8:43 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
>
>>People perform releases. They can use whatever tools
>>they want, but at the end, the only validation check
>>that really matters are those PMC members who test,
>>validate and +1 the release.
>>
>>For example, let's say that there is a codebase that
>>doesn't pass some test, but get's the required 3 +1s
>>for release and the RM doesn't pull it. Even though
>>according to the CI (or whatever) it's "not a release"
>>(it failed), as far as the PMC and the ASF is concerned,
>>it IS a release.
>>
>>Conversely, no matter what a CI may test, package and
>>drop off somewhere, if it's not voted on, it's not
>>a release.
>>
>>On May 23, 2014, at 11:33 AM, Brian LeRoux <b...@brian.io> wrote:
>>
>>> C'mon Sebb. This is circular false logic.
>>> 
>>> On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com> wrote:
>>> On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
>>> > @mark agree, there are many layers to the stated legal perception and
>>>indeed
>>> > most other OSS projects do not require a VOTE. It was communicated to
>>>me
>>> > that the VOTE specifically mitigated risk to the releasing individual
>>> > (publishing artifacts to ./dist). This, and human error, are
>>>mitigated by
>>> > not using humans to perform those actions susceptible to human error.
>>>That
>>> > is the point of a CI system and automated builds. All the actions of a
>>> > release could be done by a machine and ensuring the policy will allow
>>>that
>>> > is what I'm looking for.
>>> 
>>> However, the CI and automated build systems are created by fallible
>>>humans.
>>> 
>>> This is why it is important to ensure that the release vote contains
>>> sufficient details for an independent check of the source release
>>> contents against the SCM tag.
>>> 
>>> >
>>> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de>
>>>wrote:
>>> >>
>>> >> Brian, we only specifically talked about whether we should be
>>>allowed to
>>> >> give_intermediate_ build artifacts like nightly builds, etc to
>>>interested
>>> >> people. I personally find it a bit too restrictive to not allow to
>>>publish
>>> >> those for user testing. We (the foundation) already do this via our
>>> >> snapshots maven repos...
>>> >>
>>> >> And there are also different layers of 'legal'. There is no law in
>>>the US
>>> >> nor otherwhere in the world who requires a VOTE before an opensource
>>> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
>>> >>
>>> >> BUT: it is an ASF policy and thus binding for all our projects to
>>>VOTE on
>>> >> releases.
>>> >> And it is a really good one as it increases the technical and legal
>>> >> quality of our products! It's really a good thing to have 10+ people
>>>looking
>>> >> at a release and e.g. discovering that a file has the wrong license
>>>and
>>> >> should get removed again for example. And of course it helps
>>>reducing the
>>> >> risk from getting sued because we obviously try to minimize human
>>>errors.
>>> >>
>>> >> @Shane I'm not sure how many ASF members are subscribed to the legal
>>>list,
>>> >> maybe it is enough if we just rise awareness.
>>> >>
>>> >> LieGrue,
>>> >> strub
>>> >>
>>> >>
>>> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> "But the point already got covered and answered dozens of times imo.
>>>The
>>> >> answer is that the ALv2 protects the foundation and also the release
>>>manager
>>> >> already for all bona fides cases. End of story."
>>> >>
>>> >>
>>> >> Interesting for myself to note that it was communicated very
>>>directly to
>>> >> Cordova that this *was not* the case. Votes are a necessary
>>>component for a
>>> >> valid (aka legal) release. Also interesting for me to discover in
>>>this
>>> >> thread that the release policy is not adhered to by all ASF
>>>projects. We
>>> >> were lead to believe the rules are immutable, all projects obey
>>>them. End of
>>> >> story.
>>> >>
>>> >> I am dismayed to discover this is not the case and Cordova was
>>>singled
>>> >> out.
>>> >>
>>> >> However, clarity here is a great starting to amending the rules, and
>>>I
>>> >> recognize this effort is not forum for that. My perspective: the
>>>vote is a
>>> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
>>>computer
>>> >> (aka CI system) and not a human and I am very happy to hear there is
>>> >> precedent for this with other projects.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>> 
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>For additional commands, e-mail: legal-discuss-help@apache.org
>
>
>

Re: Release Policy

[Alex Harui <ah...@adobe.com>]

On 5/23/14 12:00 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> As soon as three folks vote +1 and there are not more -1's, another tool
>> is run to push it to the release server.
>> 
>> Would this meet requirements and be acceptable?
>
>IMO you need some time for people to look and vote -1, just because you
>got got 3 +1 doesn't mean it is a release. I can think of several cases
>where a later -1 vote has pointed out a serious bug or issue that 3
>previous +1 didn't find.
I can only think of one important issue found after we got 3 +1s and it
was from me and I'd already sent a warning on the discuss thread.  But I
can certainly think of more important issues found after we closed the
vote and shipped the release and folks started using it.  IMO, I'd rather
ship more often.  In this next 4.12.2 release, so little has changed that
waiting for 72 hours for each RC just doesn't make sense to me.

-Alex


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

Re: Release Policy

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> As soon as three folks vote +1 and there are not more -1's, another tool
> is run to push it to the release server.
> 
> Would this meet requirements and be acceptable?

IMO you need some time for people to look and vote -1, just because you got got 3 +1 doesn't mean it is a release. I can think of several cases where a later -1 vote has pointed out a serious bug or issue that 3 previous +1 didn't find.

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

Re: Release Policy

[Mark Thomas <ma...@apache.org>]

On 23/05/2014 20:08, Alex Harui wrote:
> Trying to keep this part of the thread from derailing…
> 
> Brian, I think at Apache there will always be a vote required, and a
> minimum of 3 humans required to review a release before shipping.  I
> don't think we have the ability to automate the review of the
> headers/LICENSE/NOTICE, but we can certainly try to limit the amount of
> human time and human error involved, so I disagree that voting trumps
> the need for tools.  That's why I'm probing the notion that a decent set
> of tools and not requiring 72 hours voting can get releasing down to a
> few hours after the CI finishes a build, if you have 3 folks handy to vote.

Spinning the 72-hour part off.

I'm wondering if there is a correlation between the diversity of the PMC
and the view that 72 hours is too long. My thinking is that if most of
the PMC is from 2 or 3 companies then organising the necessary
activities to enable votes to be made for a release to pass is fairly
easy and 72 hours would look excessively long. I am primarily involved
in Tomcat and Commons where (to my knowledge) no one company accounts
for more than ~15% of the PMC and 72 hours does seem a reasonable time
to give everyone a chance to vote.

I'm not trying to say one PMC is 'better' than any other, just trying to
get a better understanding of why one community would be happier with a
much shorter voting period than the communities with which I am familiar.

Alongside that I've been mulling over what sort of process could be used
to shorten the vote and have come up with the following:

For a given release:
- the entire voting period (for all RCs) should be no shorter than
  72 hours.
- each RC will have a voting period of at least 24 hours unless the
  RC vote is cancelled in which case there is no minimum
- any PMC member may request an RC's voting period be extended to 72
  hours without having to provide any justification
- releases to address critical security vulnerabilities may reduce the
  voting periods to any length at the discretion of the release manager

Thoughts?

Mark


> 
> -Alex
> 
> From: Brian LeRoux <b@brian.io <ma...@brian.io>>
> Reply-To: "legal-discuss@apache.org <ma...@apache.org>"
> <legal-discuss@apache.org <ma...@apache.org>>
> Date: Friday, May 23, 2014 11:33 AM
> To: legal discuss <legal-discuss@apache.org
> <ma...@apache.org>>
> Subject: Re: Release Policy
> 
> Yes it is as JJ says as long as a vote happens the tools matter not.
> Though why the vote has to happen is yet to be clarified other than
> meandering justifications.
> 
> On May 23, 2014 11:56 AM, "Alex Harui" <aharui@adobe.com
> <ma...@adobe.com>> wrote:
> 
>     This current proposal no longer requires 72 hour voting.  To me, this
>     means that we could eventually automate releasing to the point where the
>     CI prepares a set of packages with MD5 sums separately prepares a report
>     of all new files and all files with changes to the headers.
> 
>     The RM then runs another tool that downloads the packages, verifies the
>     MD5, signs with the PGP key (yes, the RM has to type in their password)
>     and uploads it to the RC server.
> 
>     Then three folks run another tool that downloads the packages, verifies
>     signatures, expands the source package, runs RAT, downloads an SCM tag,
>     compares the source against the tag, runs the default ant or maven
>     target,
>     and prepares a report with the LICENSE and NOTICE files and headers
>     of new
>     files and changed headers and RAT output.
> 
>     As soon as three folks vote +1 and there are not more -1's, another tool
>     is run to push it to the release server.
> 
>     Would this meet requirements and be acceptable?
> 
>     What if a machine did the downloading of packages, signature
>     verification,
>     RAT, SCM compare and build so the voters only need to review a report
>     before voting.  Would that also meet requirements and be acceptable?
> 
>     Thanks,
>     -Alex
> 
>     On 5/23/14 8:43 AM, "Jim Jagielski" <jim@jaguNET.com
>     <ma...@jaguNET.com>> wrote:
> 
>     >People perform releases. They can use whatever tools
>     >they want, but at the end, the only validation check
>     >that really matters are those PMC members who test,
>     >validate and +1 the release.
>     >
>     >For example, let's say that there is a codebase that
>     >doesn't pass some test, but get's the required 3 +1s
>     >for release and the RM doesn't pull it. Even though
>     >according to the CI (or whatever) it's "not a release"
>     >(it failed), as far as the PMC and the ASF is concerned,
>     >it IS a release.
>     >
>     >Conversely, no matter what a CI may test, package and
>     >drop off somewhere, if it's not voted on, it's not
>     >a release.
>     >
>     >On May 23, 2014, at 11:33 AM, Brian LeRoux <b@brian.io <ma...@brian.io>> wrote:
>     >
>     >> C'mon Sebb. This is circular false logic.
>     >>
>     >> On May 23, 2014 10:29 AM, "sebb" <sebbaz@gmail.com <ma...@gmail.com>> wrote:
>     >> On 23 May 2014 16:01, Brian LeRoux <b@brian.io <ma...@brian.io>> wrote:
>     >> > @mark agree, there are many layers to the stated legal perception and
>     >>indeed
>     >> > most other OSS projects do not require a VOTE. It was communicated to
>     >>me
>     >> > that the VOTE specifically mitigated risk to the releasing individual
>     >> > (publishing artifacts to ./dist). This, and human error, are
>     >>mitigated by
>     >> > not using humans to perform those actions susceptible to human error.
>     >>That
>     >> > is the point of a CI system and automated builds. All the actions of a
>     >> > release could be done by a machine and ensuring the policy will allow
>     >>that
>     >> > is what I'm looking for.
>     >>
>     >> However, the CI and automated build systems are created by fallible
>     >>humans.
>     >>
>     >> This is why it is important to ensure that the release vote contains
>     >> sufficient details for an independent check of the source release
>     >> contents against the SCM tag.
>     >>
>     >> >
>     >> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <struberg@yahoo.de <ma...@yahoo.de>>
>     >>wrote:
>     >> >>
>     >> >> Brian, we only specifically talked about whether we should be
>     >>allowed to
>     >> >> give_intermediate_ build artifacts like nightly builds, etc to
>     >>interested
>     >> >> people. I personally find it a bit too restrictive to not allow to
>     >>publish
>     >> >> those for user testing. We (the foundation) already do this via our
>     >> >> snapshots maven repos...
>     >> >>
>     >> >> And there are also different layers of 'legal'. There is no law in
>     >>the US
>     >> >> nor otherwhere in the world who requires a VOTE before an opensource
>     >> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
>     >> >>
>     >> >> BUT: it is an ASF policy and thus binding for all our projects to
>     >>VOTE on
>     >> >> releases.
>     >> >> And it is a really good one as it increases the technical and legal
>     >> >> quality of our products! It's really a good thing to have 10+ people
>     >>looking
>     >> >> at a release and e.g. discovering that a file has the wrong license
>     >>and
>     >> >> should get removed again for example. And of course it helps
>     >>reducing the
>     >> >> risk from getting sued because we obviously try to minimize human
>     >>errors.
>     >> >>
>     >> >> @Shane I'm not sure how many ASF members are subscribed to the legal
>     >>list,
>     >> >> maybe it is enough if we just rise awareness.
>     >> >>
>     >> >> LieGrue,
>     >> >> strub
>     >> >>
>     >> >>
>     >> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b@brian.io <ma...@brian.io>> wrote:
>     >> >>
>     >> >>
>     >> >>
>     >> >>
>     >> >>
>     >> >> "But the point already got covered and answered dozens of times imo.
>     >>The
>     >> >> answer is that the ALv2 protects the foundation and also the release
>     >>manager
>     >> >> already for all bona fides cases. End of story."
>     >> >>
>     >> >>
>     >> >> Interesting for myself to note that it was communicated very
>     >>directly to
>     >> >> Cordova that this *was not* the case. Votes are a necessary
>     >>component for a
>     >> >> valid (aka legal) release. Also interesting for me to discover in
>     >>this
>     >> >> thread that the release policy is not adhered to by all ASF
>     >>projects. We
>     >> >> were lead to believe the rules are immutable, all projects obey
>     >>them. End of
>     >> >> story.
>     >> >>
>     >> >> I am dismayed to discover this is not the case and Cordova was
>     >>singled
>     >> >> out.
>     >> >>
>     >> >> However, clarity here is a great starting to amending the rules, and
>     >>I
>     >> >> recognize this effort is not forum for that. My perspective: the
>     >>vote is a
>     >> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
>     >>computer
>     >> >> (aka CI system) and not a human and I am very happy to hear there is
>     >> >> precedent for this with other projects.
>     >> >>
>     >> >>
>     >> >>
>     >> >>
>     >> >
>     >>
>     >> ---------------------------------------------------------------------
>     >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>     <ma...@apache.org>
>     >> For additional commands, e-mail: legal-discuss-help@apache.org <ma...@apache.org>
>     >>
>     >
>     >
>     >---------------------------------------------------------------------
>     >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>     <ma...@apache.org>
>     >For additional commands, e-mail: legal-discuss-help@apache.org <ma...@apache.org>
>     >
> 
> 
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>     <ma...@apache.org>
>     For additional commands, e-mail: legal-discuss-help@apache.org
>     <ma...@apache.org>
> 


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

Re: Release Policy

[Alex Harui <ah...@adobe.com>]

On 5/23/14 12:31 PM, "Mark Thomas" <ma...@apache.org> wrote:
>One thing that has just occurred to me that I think would make a big
>difference is if a "release" CI system built the binaries from a source
>tarball rather than directly from version control. Doing this removes
>all the "How do you prove what the CI system built is the same as would
>be built from the source tarball?" issues.
>
>Thoughts?
Exactly.  My proposal is that voters review output from a different
automation process that validates the source package.  I already use an
ant script to do that when voting.  It makes sure I don't skip steps. It
hoists editor windows in my face with LICENSE and NOTICE and the rat
report.
>
>(I don't think this helps with the 72-hour window though.)
IMO, we trust RMs and PMCs enough already that we could trust them with
subjectivity in how long the vote lasts.  If the project gets complaints
that the window isn't long enough, the RM will likely respond
appropriately.  The ultimate goal is how to best serve the community.  For
RC1 of the mainstream Flex package, I would always wait at least 24 hours
and want to see votes from different geographies, even if I got 3 US votes
in the first 15 minutes.  For RCn, after we've hopefully vetted the major
issues and are just tweaking RELEASE_NOTES, why wait 72 hours?

>
>Mark
>
>> 
>> -Alex
>> 
>> From: Brian LeRoux <b@brian.io <ma...@brian.io>>
>> Reply-To: "legal-discuss@apache.org <ma...@apache.org>"
>> <legal-discuss@apache.org <ma...@apache.org>>
>> Date: Friday, May 23, 2014 11:33 AM
>> To: legal discuss <legal-discuss@apache.org
>> <ma...@apache.org>>
>> Subject: Re: Release Policy
>> 
>> Yes it is as JJ says as long as a vote happens the tools matter not.
>> Though why the vote has to happen is yet to be clarified other than
>> meandering justifications.
>> 
>> On May 23, 2014 11:56 AM, "Alex Harui" <aharui@adobe.com
>> <ma...@adobe.com>> wrote:
>> 
>>     This current proposal no longer requires 72 hour voting.  To me,
>>this
>>     means that we could eventually automate releasing to the point
>>where the
>>     CI prepares a set of packages with MD5 sums separately prepares a
>>report
>>     of all new files and all files with changes to the headers.
>> 
>>     The RM then runs another tool that downloads the packages, verifies
>>the
>>     MD5, signs with the PGP key (yes, the RM has to type in their
>>password)
>>     and uploads it to the RC server.
>> 
>>     Then three folks run another tool that downloads the packages,
>>verifies
>>     signatures, expands the source package, runs RAT, downloads an SCM
>>tag,
>>     compares the source against the tag, runs the default ant or maven
>>     target,
>>     and prepares a report with the LICENSE and NOTICE files and headers
>>     of new
>>     files and changed headers and RAT output.
>> 
>>     As soon as three folks vote +1 and there are not more -1's, another
>>tool
>>     is run to push it to the release server.
>> 
>>     Would this meet requirements and be acceptable?
>> 
>>     What if a machine did the downloading of packages, signature
>>     verification,
>>     RAT, SCM compare and build so the voters only need to review a
>>report
>>     before voting.  Would that also meet requirements and be acceptable?
>> 
>>     Thanks,
>>     -Alex
>> 
>>     On 5/23/14 8:43 AM, "Jim Jagielski" <jim@jaguNET.com
>>     <ma...@jaguNET.com>> wrote:
>> 
>>     >People perform releases. They can use whatever tools
>>     >they want, but at the end, the only validation check
>>     >that really matters are those PMC members who test,
>>     >validate and +1 the release.
>>     >
>>     >For example, let's say that there is a codebase that
>>     >doesn't pass some test, but get's the required 3 +1s
>>     >for release and the RM doesn't pull it. Even though
>>     >according to the CI (or whatever) it's "not a release"
>>     >(it failed), as far as the PMC and the ASF is concerned,
>>     >it IS a release.
>>     >
>>     >Conversely, no matter what a CI may test, package and
>>     >drop off somewhere, if it's not voted on, it's not
>>     >a release.
>>     >
>>     >On May 23, 2014, at 11:33 AM, Brian LeRoux <b@brian.io
>><ma...@brian.io>> wrote:
>>     >
>>     >> C'mon Sebb. This is circular false logic.
>>     >>
>>     >> On May 23, 2014 10:29 AM, "sebb" <sebbaz@gmail.com
>><ma...@gmail.com>> wrote:
>>     >> On 23 May 2014 16:01, Brian LeRoux <b@brian.io
>><ma...@brian.io>> wrote:
>>     >> > @mark agree, there are many layers to the stated legal
>>perception and
>>     >>indeed
>>     >> > most other OSS projects do not require a VOTE. It was
>>communicated to
>>     >>me
>>     >> > that the VOTE specifically mitigated risk to the releasing
>>individual
>>     >> > (publishing artifacts to ./dist). This, and human error, are
>>     >>mitigated by
>>     >> > not using humans to perform those actions susceptible to human
>>error.
>>     >>That
>>     >> > is the point of a CI system and automated builds. All the
>>actions of a
>>     >> > release could be done by a machine and ensuring the policy
>>will allow
>>     >>that
>>     >> > is what I'm looking for.
>>     >>
>>     >> However, the CI and automated build systems are created by
>>fallible
>>     >>humans.
>>     >>
>>     >> This is why it is important to ensure that the release vote
>>contains
>>     >> sufficient details for an independent check of the source release
>>     >> contents against the SCM tag.
>>     >>
>>     >> >
>>     >> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg
>><struberg@yahoo.de <ma...@yahoo.de>>
>>     >>wrote:
>>     >> >>
>>     >> >> Brian, we only specifically talked about whether we should be
>>     >>allowed to
>>     >> >> give_intermediate_ build artifacts like nightly builds, etc to
>>     >>interested
>>     >> >> people. I personally find it a bit too restrictive to not
>>allow to
>>     >>publish
>>     >> >> those for user testing. We (the foundation) already do this
>>via our
>>     >> >> snapshots maven repos...
>>     >> >>
>>     >> >> And there are also different layers of 'legal'. There is no
>>law in
>>     >>the US
>>     >> >> nor otherwhere in the world who requires a VOTE before an
>>opensource
>>     >> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
>>     >> >>
>>     >> >> BUT: it is an ASF policy and thus binding for all our
>>projects to
>>     >>VOTE on
>>     >> >> releases.
>>     >> >> And it is a really good one as it increases the technical and
>>legal
>>     >> >> quality of our products! It's really a good thing to have 10+
>>people
>>     >>looking
>>     >> >> at a release and e.g. discovering that a file has the wrong
>>license
>>     >>and
>>     >> >> should get removed again for example. And of course it helps
>>     >>reducing the
>>     >> >> risk from getting sued because we obviously try to minimize
>>human
>>     >>errors.
>>     >> >>
>>     >> >> @Shane I'm not sure how many ASF members are subscribed to
>>the legal
>>     >>list,
>>     >> >> maybe it is enough if we just rise awareness.
>>     >> >>
>>     >> >> LieGrue,
>>     >> >> strub
>>     >> >>
>>     >> >>
>>     >> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b@brian.io
>><ma...@brian.io>> wrote:
>>     >> >>
>>     >> >>
>>     >> >>
>>     >> >>
>>     >> >>
>>     >> >> "But the point already got covered and answered dozens of
>>times imo.
>>     >>The
>>     >> >> answer is that the ALv2 protects the foundation and also the
>>release
>>     >>manager
>>     >> >> already for all bona fides cases. End of story."
>>     >> >>
>>     >> >>
>>     >> >> Interesting for myself to note that it was communicated very
>>     >>directly to
>>     >> >> Cordova that this *was not* the case. Votes are a necessary
>>     >>component for a
>>     >> >> valid (aka legal) release. Also interesting for me to
>>discover in
>>     >>this
>>     >> >> thread that the release policy is not adhered to by all ASF
>>     >>projects. We
>>     >> >> were lead to believe the rules are immutable, all projects
>>obey
>>     >>them. End of
>>     >> >> story.
>>     >> >>
>>     >> >> I am dismayed to discover this is not the case and Cordova was
>>     >>singled
>>     >> >> out.
>>     >> >>
>>     >> >> However, clarity here is a great starting to amending the
>>rules, and
>>     >>I
>>     >> >> recognize this effort is not forum for that. My perspective:
>>the
>>     >>vote is a
>>     >> >> SHOULD and most certainly SHA verifciation SHOULD be the job
>>of a
>>     >>computer
>>     >> >> (aka CI system) and not a human and I am very happy to hear
>>there is
>>     >> >> precedent for this with other projects.
>>     >> >>
>>     >> >>
>>     >> >>
>>     >> >>
>>     >> >
>>     >>
>>     >> 
>>---------------------------------------------------------------------
>>     >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>     <ma...@apache.org>
>>     >> For additional commands, e-mail: legal-discuss-help@apache.org
>><ma...@apache.org>
>>     >>
>>     >
>>     >
>>     
>>>---------------------------------------------------------------------
>>     >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>     <ma...@apache.org>
>>     >For additional commands, e-mail: legal-discuss-help@apache.org
>><ma...@apache.org>
>>     >
>> 
>> 
>>     
>>---------------------------------------------------------------------
>>     To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>     <ma...@apache.org>
>>     For additional commands, e-mail: legal-discuss-help@apache.org
>>     <ma...@apache.org>
>> 
>
>
>---------------------------------------------------------------------
>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

Re: Release Policy

[Mark Thomas <ma...@apache.org>]

On 23/05/2014 20:08, Alex Harui wrote:
> Trying to keep this part of the thread from derailing…
> 
> Brian, I think at Apache there will always be a vote required, and a
> minimum of 3 humans required to review a release before shipping.  I
> don't think we have the ability to automate the review of the
> headers/LICENSE/NOTICE, but we can certainly try to limit the amount of
> human time and human error involved, so I disagree that voting trumps
> the need for tools.  That's why I'm probing the notion that a decent set
> of tools and not requiring 72 hours voting can get releasing down to a
> few hours after the CI finishes a build, if you have 3 folks handy to vote.

This is heading off topic but I think it is a useful discussion to have.

That kind of misses the point that an ASF release is a source tarball
and the binaries are merely a convenience. (Yes I appreciate that for
some projects 99.999% of users want the binaries but that doesn't change
the ASF's position on this.)

One thing that has just occurred to me that I think would make a big
difference is if a "release" CI system built the binaries from a source
tarball rather than directly from version control. Doing this removes
all the "How do you prove what the CI system built is the same as would
be built from the source tarball?" issues.

Thoughts?

(I don't think this helps with the 72-hour window though.)

Mark

> 
> -Alex
> 
> From: Brian LeRoux <b@brian.io <ma...@brian.io>>
> Reply-To: "legal-discuss@apache.org <ma...@apache.org>"
> <legal-discuss@apache.org <ma...@apache.org>>
> Date: Friday, May 23, 2014 11:33 AM
> To: legal discuss <legal-discuss@apache.org
> <ma...@apache.org>>
> Subject: Re: Release Policy
> 
> Yes it is as JJ says as long as a vote happens the tools matter not.
> Though why the vote has to happen is yet to be clarified other than
> meandering justifications.
> 
> On May 23, 2014 11:56 AM, "Alex Harui" <aharui@adobe.com
> <ma...@adobe.com>> wrote:
> 
>     This current proposal no longer requires 72 hour voting.  To me, this
>     means that we could eventually automate releasing to the point where the
>     CI prepares a set of packages with MD5 sums separately prepares a report
>     of all new files and all files with changes to the headers.
> 
>     The RM then runs another tool that downloads the packages, verifies the
>     MD5, signs with the PGP key (yes, the RM has to type in their password)
>     and uploads it to the RC server.
> 
>     Then three folks run another tool that downloads the packages, verifies
>     signatures, expands the source package, runs RAT, downloads an SCM tag,
>     compares the source against the tag, runs the default ant or maven
>     target,
>     and prepares a report with the LICENSE and NOTICE files and headers
>     of new
>     files and changed headers and RAT output.
> 
>     As soon as three folks vote +1 and there are not more -1's, another tool
>     is run to push it to the release server.
> 
>     Would this meet requirements and be acceptable?
> 
>     What if a machine did the downloading of packages, signature
>     verification,
>     RAT, SCM compare and build so the voters only need to review a report
>     before voting.  Would that also meet requirements and be acceptable?
> 
>     Thanks,
>     -Alex
> 
>     On 5/23/14 8:43 AM, "Jim Jagielski" <jim@jaguNET.com
>     <ma...@jaguNET.com>> wrote:
> 
>     >People perform releases. They can use whatever tools
>     >they want, but at the end, the only validation check
>     >that really matters are those PMC members who test,
>     >validate and +1 the release.
>     >
>     >For example, let's say that there is a codebase that
>     >doesn't pass some test, but get's the required 3 +1s
>     >for release and the RM doesn't pull it. Even though
>     >according to the CI (or whatever) it's "not a release"
>     >(it failed), as far as the PMC and the ASF is concerned,
>     >it IS a release.
>     >
>     >Conversely, no matter what a CI may test, package and
>     >drop off somewhere, if it's not voted on, it's not
>     >a release.
>     >
>     >On May 23, 2014, at 11:33 AM, Brian LeRoux <b@brian.io <ma...@brian.io>> wrote:
>     >
>     >> C'mon Sebb. This is circular false logic.
>     >>
>     >> On May 23, 2014 10:29 AM, "sebb" <sebbaz@gmail.com <ma...@gmail.com>> wrote:
>     >> On 23 May 2014 16:01, Brian LeRoux <b@brian.io <ma...@brian.io>> wrote:
>     >> > @mark agree, there are many layers to the stated legal perception and
>     >>indeed
>     >> > most other OSS projects do not require a VOTE. It was communicated to
>     >>me
>     >> > that the VOTE specifically mitigated risk to the releasing individual
>     >> > (publishing artifacts to ./dist). This, and human error, are
>     >>mitigated by
>     >> > not using humans to perform those actions susceptible to human error.
>     >>That
>     >> > is the point of a CI system and automated builds. All the actions of a
>     >> > release could be done by a machine and ensuring the policy will allow
>     >>that
>     >> > is what I'm looking for.
>     >>
>     >> However, the CI and automated build systems are created by fallible
>     >>humans.
>     >>
>     >> This is why it is important to ensure that the release vote contains
>     >> sufficient details for an independent check of the source release
>     >> contents against the SCM tag.
>     >>
>     >> >
>     >> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <struberg@yahoo.de <ma...@yahoo.de>>
>     >>wrote:
>     >> >>
>     >> >> Brian, we only specifically talked about whether we should be
>     >>allowed to
>     >> >> give_intermediate_ build artifacts like nightly builds, etc to
>     >>interested
>     >> >> people. I personally find it a bit too restrictive to not allow to
>     >>publish
>     >> >> those for user testing. We (the foundation) already do this via our
>     >> >> snapshots maven repos...
>     >> >>
>     >> >> And there are also different layers of 'legal'. There is no law in
>     >>the US
>     >> >> nor otherwhere in the world who requires a VOTE before an opensource
>     >> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
>     >> >>
>     >> >> BUT: it is an ASF policy and thus binding for all our projects to
>     >>VOTE on
>     >> >> releases.
>     >> >> And it is a really good one as it increases the technical and legal
>     >> >> quality of our products! It's really a good thing to have 10+ people
>     >>looking
>     >> >> at a release and e.g. discovering that a file has the wrong license
>     >>and
>     >> >> should get removed again for example. And of course it helps
>     >>reducing the
>     >> >> risk from getting sued because we obviously try to minimize human
>     >>errors.
>     >> >>
>     >> >> @Shane I'm not sure how many ASF members are subscribed to the legal
>     >>list,
>     >> >> maybe it is enough if we just rise awareness.
>     >> >>
>     >> >> LieGrue,
>     >> >> strub
>     >> >>
>     >> >>
>     >> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b@brian.io <ma...@brian.io>> wrote:
>     >> >>
>     >> >>
>     >> >>
>     >> >>
>     >> >>
>     >> >> "But the point already got covered and answered dozens of times imo.
>     >>The
>     >> >> answer is that the ALv2 protects the foundation and also the release
>     >>manager
>     >> >> already for all bona fides cases. End of story."
>     >> >>
>     >> >>
>     >> >> Interesting for myself to note that it was communicated very
>     >>directly to
>     >> >> Cordova that this *was not* the case. Votes are a necessary
>     >>component for a
>     >> >> valid (aka legal) release. Also interesting for me to discover in
>     >>this
>     >> >> thread that the release policy is not adhered to by all ASF
>     >>projects. We
>     >> >> were lead to believe the rules are immutable, all projects obey
>     >>them. End of
>     >> >> story.
>     >> >>
>     >> >> I am dismayed to discover this is not the case and Cordova was
>     >>singled
>     >> >> out.
>     >> >>
>     >> >> However, clarity here is a great starting to amending the rules, and
>     >>I
>     >> >> recognize this effort is not forum for that. My perspective: the
>     >>vote is a
>     >> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
>     >>computer
>     >> >> (aka CI system) and not a human and I am very happy to hear there is
>     >> >> precedent for this with other projects.
>     >> >>
>     >> >>
>     >> >>
>     >> >>
>     >> >
>     >>
>     >> ---------------------------------------------------------------------
>     >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>     <ma...@apache.org>
>     >> For additional commands, e-mail: legal-discuss-help@apache.org <ma...@apache.org>
>     >>
>     >
>     >
>     >---------------------------------------------------------------------
>     >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>     <ma...@apache.org>
>     >For additional commands, e-mail: legal-discuss-help@apache.org <ma...@apache.org>
>     >
> 
> 
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>     <ma...@apache.org>
>     For additional commands, e-mail: legal-discuss-help@apache.org
>     <ma...@apache.org>
> 


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

Re: Release Policy

[Alex Harui <ah...@adobe.com>]

Trying to keep this part of the thread from derailing…

Brian, I think at Apache there will always be a vote required, and a minimum of 3 humans required to review a release before shipping.  I don't think we have the ability to automate the review of the headers/LICENSE/NOTICE, but we can certainly try to limit the amount of human time and human error involved, so I disagree that voting trumps the need for tools.  That's why I'm probing the notion that a decent set of tools and not requiring 72 hours voting can get releasing down to a few hours after the CI finishes a build, if you have 3 folks handy to vote.

-Alex

From: Brian LeRoux <b@...@brian.io>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Friday, May 23, 2014 11:33 AM
To: legal discuss <le...@apache.org>>
Subject: Re: Release Policy


Yes it is as JJ says as long as a vote happens the tools matter not. Though why the vote has to happen is yet to be clarified other than meandering justifications.

On May 23, 2014 11:56 AM, "Alex Harui" <ah...@adobe.com>> wrote:
This current proposal no longer requires 72 hour voting.  To me, this
means that we could eventually automate releasing to the point where the
CI prepares a set of packages with MD5 sums separately prepares a report
of all new files and all files with changes to the headers.

The RM then runs another tool that downloads the packages, verifies the
MD5, signs with the PGP key (yes, the RM has to type in their password)
and uploads it to the RC server.

Then three folks run another tool that downloads the packages, verifies
signatures, expands the source package, runs RAT, downloads an SCM tag,
compares the source against the tag, runs the default ant or maven target,
and prepares a report with the LICENSE and NOTICE files and headers of new
files and changed headers and RAT output.

As soon as three folks vote +1 and there are not more -1's, another tool
is run to push it to the release server.

Would this meet requirements and be acceptable?

What if a machine did the downloading of packages, signature verification,
RAT, SCM compare and build so the voters only need to review a report
before voting.  Would that also meet requirements and be acceptable?

Thanks,
-Alex

On 5/23/14 8:43 AM, "Jim Jagielski" <ji...@jaguNET.com>> wrote:

>People perform releases. They can use whatever tools
>they want, but at the end, the only validation check
>that really matters are those PMC members who test,
>validate and +1 the release.
>
>For example, let's say that there is a codebase that
>doesn't pass some test, but get's the required 3 +1s
>for release and the RM doesn't pull it. Even though
>according to the CI (or whatever) it's "not a release"
>(it failed), as far as the PMC and the ASF is concerned,
>it IS a release.
>
>Conversely, no matter what a CI may test, package and
>drop off somewhere, if it's not voted on, it's not
>a release.
>
>On May 23, 2014, at 11:33 AM, Brian LeRoux <b@...@brian.io>> wrote:
>
>> C'mon Sebb. This is circular false logic.
>>
>> On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com>> wrote:
>> On 23 May 2014 16:01, Brian LeRoux <b@...@brian.io>> wrote:
>> > @mark agree, there are many layers to the stated legal perception and
>>indeed
>> > most other OSS projects do not require a VOTE. It was communicated to
>>me
>> > that the VOTE specifically mitigated risk to the releasing individual
>> > (publishing artifacts to ./dist). This, and human error, are
>>mitigated by
>> > not using humans to perform those actions susceptible to human error.
>>That
>> > is the point of a CI system and automated builds. All the actions of a
>> > release could be done by a machine and ensuring the policy will allow
>>that
>> > is what I'm looking for.
>>
>> However, the CI and automated build systems are created by fallible
>>humans.
>>
>> This is why it is important to ensure that the release vote contains
>> sufficient details for an independent check of the source release
>> contents against the SCM tag.
>>
>> >
>> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de>>
>>wrote:
>> >>
>> >> Brian, we only specifically talked about whether we should be
>>allowed to
>> >> give_intermediate_ build artifacts like nightly builds, etc to
>>interested
>> >> people. I personally find it a bit too restrictive to not allow to
>>publish
>> >> those for user testing. We (the foundation) already do this via our
>> >> snapshots maven repos...
>> >>
>> >> And there are also different layers of 'legal'. There is no law in
>>the US
>> >> nor otherwhere in the world who requires a VOTE before an opensource
>> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
>> >>
>> >> BUT: it is an ASF policy and thus binding for all our projects to
>>VOTE on
>> >> releases.
>> >> And it is a really good one as it increases the technical and legal
>> >> quality of our products! It's really a good thing to have 10+ people
>>looking
>> >> at a release and e.g. discovering that a file has the wrong license
>>and
>> >> should get removed again for example. And of course it helps
>>reducing the
>> >> risk from getting sued because we obviously try to minimize human
>>errors.
>> >>
>> >> @Shane I'm not sure how many ASF members are subscribed to the legal
>>list,
>> >> maybe it is enough if we just rise awareness.
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >>
>> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b@...@brian.io>> wrote:
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> "But the point already got covered and answered dozens of times imo.
>>The
>> >> answer is that the ALv2 protects the foundation and also the release
>>manager
>> >> already for all bona fides cases. End of story."
>> >>
>> >>
>> >> Interesting for myself to note that it was communicated very
>>directly to
>> >> Cordova that this *was not* the case. Votes are a necessary
>>component for a
>> >> valid (aka legal) release. Also interesting for me to discover in
>>this
>> >> thread that the release policy is not adhered to by all ASF
>>projects. We
>> >> were lead to believe the rules are immutable, all projects obey
>>them. End of
>> >> story.
>> >>
>> >> I am dismayed to discover this is not the case and Cordova was
>>singled
>> >> out.
>> >>
>> >> However, clarity here is a great starting to amending the rules, and
>>I
>> >> recognize this effort is not forum for that. My perspective: the
>>vote is a
>> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
>>computer
>> >> (aka CI system) and not a human and I am very happy to hear there is
>> >> precedent for this with other projects.
>> >>
>> >>
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
>> For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
>For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
>


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

Re: Release Policy

[Brian LeRoux <b...@brian.io>]

IMO, we did not have release difficulties until Sebb and the board to
inform us we were doing it wrong. Shipping was something we were proud to
have a bias for as it is fairly proven at this point in our industry to be
the main reason projects fail. Going from releasing often to having emails
about whether we're going to ship or not is not sending a positive message
to the community! Anyhow. =/

Since then, December I think, we've been revamping our release tooling to
support the policy amidst time lost arguing about how to best do that. We
can't turn back time but we certainly can help avoid this happening again
and mitigate the very real perception issues you outline below.


On Fri, May 23, 2014 at 4:02 PM, Dave Cottlehuber <dc...@jsonified.com> wrote:

>  > On May 23, 2014 11:47 AM, "Jim Jagielski" wrote:
> > >
> > > This was discussed, at length, both on various mailing
> > > lists as well as at the f2f rountable @ ApacheCon.
> > >
> >
> >
> > You are aware that people on this list didn't attend ApacheCon for
> either personal or professional reasons?
> >
>
> Also my case however I’ve followed the mailing lists & the current updated
> http://www.apache.org/dev/release.html and
> http://www.apache.org/dev/release-publishing cover the requirements &
> reasoning for me clearly.
>
> Joe, Brian - is there anything in the 2 links above that isn’t
> sufficiently clear, that you’d need improved?
>
> BTW prior to the earlier discussions on this list, I also wasn’t aware of
> the reasoning behind the ASF release processes, at least the mandated
> components, e.g. ensuring appropriate licencing for all included
> components. Obvious in hindsight. For CouchDB we have had, for a long time,
> an automated check in `make distcheck` that ensures only files with an ALv2
> header can come through, or a committer needs to add an exclusion, not
> unlike updating svn/gitignore. This helps a lot.
>
> > Not that I want to ever see you personally given how miserable you are
> over e-mail.
>
> Unnecessary.
>
> > > > On May 23, 2014 11:56 AM, "Alex Harui" wrote:
> > > > This current proposal no longer requires 72 hour voting. To me, this
> > > > means that we could eventually automate releasing to the point where
> the
> > > > CI prepares a set of packages with MD5 sums separately prepares a
> report
> > > > of all new files and all files with changes to the headers.
> > > >
> > > > The RM then runs another tool that downloads the packages, verifies
> the
> > > > MD5, signs with the PGP key (yes, the RM has to type in their
> password)
> > > > and uploads it to the RC server.
> > > >
> > > > Then three folks run another tool that downloads the packages,
> verifies
> > > > signatures, expands the source package, runs RAT, downloads an SCM
> tag,
> > > > compares the source against the tag, runs the default ant or maven
> target,
> > > > and prepares a report with the LICENSE and NOTICE files and headers
> of new
> > > > files and changed headers and RAT output.
> > > >
> > > > As soon as three folks vote +1 and there are not more -1's, another
> tool
> > > > is run to push it to the release server.
> > > >
> > > > Would this meet requirements and be acceptable?
>
> From my limited ASF experience, I’d guess that this meets the Foundation’s
> requirements (viz the earlier URLs) and if your community’s OK with it why
> not. 72 hours IIRC is not mandated, its a guideline across many projects
> based on striking a balance between full consensus and fast releases.
>
> > > > What if a machine did the downloading of packages, signature
> verification,
> > > > RAT, SCM compare and build so the voters only need to review a report
> > > > before voting. Would that also meet requirements and be acceptable?
>
> > > > Thanks,
> > > > -Alex
>
> I have a personal script that does most of this for me for CouchDB, and
> assuming you’re on top of the commits coming through anyway, it seems
> “sufficient to meet criteria”. If everybody contributed to that script for
> a given project it could be a very comprehensive check.
>
> However the bigger picture here is that the Foundation partly exists to
> provide a legal cushion for projects & their representatives. We have a
> number of ASF people who have experience of the need for that cushion, and
> as somebody who used to work for Telcos and Big Tech, I fully understand
> the need for that cushion.
>
> I’m reluctant to pull all the feathers out of the cushion, only to find
> later that a crack-smoking team of opposing lawyers just pwned my house and
> put my family on the street. It’s speculation to say that removing all but
> the final Rubber Stamp +1 (I read the report, its sweet bro) is
> *definitely* legally sustainable in the face of determined opposition from
> for example Patent Trolls. The potentially increased risk is simply not
> quantifiable, esp IANAL etc.
>
> Finally, for the “older ASFers” here. I get your concerns, and I’ve had
> enough big corp business experience to understand the continued need to
> keep that risk managed.
>
> However I suspect that a large part of Cordova peoples’ concerns (and
> others) is that there is a foaming, cresting, evolving wave of open source
> out there, where hundreds of thousands of people surf and live on the
> bleeding edge of packages, across javascript, haskell, erlang, clojure and
> others, who are not afraid of a few incompatibilities along the way. Those
> people pushing the limits of what they can do are ones we should bring, and
> keep, on board.
>
> We need to ensure that the ASF retains its pride of place for Superb
> Software, in this new mad crazy world, without compromising its principles.
> Whether this means refining and evolving the acceptable level of
> automation, continuing the vastly improved release process documentation,
> or something else, make no mistake — the single biggest risk to the
> Foundation’s long term existence is to be labelled a dinosaur — whether
> unfairly or not.
>
> Brian, Joe, Alex, if you got this far, are you implying that a/the reason
> for the drop in release cadence for Cordova was as a result of release
> process difficulties? What can we do to help your project? Anything else?
>
> A+
> dch
> --
> Sent from my Couch
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

Re: Release Policy

[Dave Cottlehuber <dc...@jsonified.com>]

 > On May 23, 2014 11:47 AM, "Jim Jagielski" wrote:
> >
> > This was discussed, at length, both on various mailing
> > lists as well as at the f2f rountable @ ApacheCon.
> >
>  
>  
> You are aware that people on this list didn't attend ApacheCon for either personal or professional reasons?  
>  

Also my case however I’ve followed the mailing lists & the current updated http://www.apache.org/dev/release.html and http://www.apache.org/dev/release-publishing cover the requirements & reasoning for me clearly.

Joe, Brian - is there anything in the 2 links above that isn’t sufficiently clear, that you’d need improved?

BTW prior to the earlier discussions on this list, I also wasn’t aware of the reasoning behind the ASF release processes, at least the mandated components, e.g. ensuring appropriate licencing for all included components. Obvious in hindsight. For CouchDB we have had, for a long time, an automated check in `make distcheck` that ensures only files with an ALv2 header can come through, or a committer needs to add an exclusion, not unlike updating svn/gitignore. This helps a lot.

> Not that I want to ever see you personally given how miserable you are over e-mail.

Unnecessary.

> > > On May 23, 2014 11:56 AM, "Alex Harui" wrote:
> > > This current proposal no longer requires 72 hour voting. To me, this
> > > means that we could eventually automate releasing to the point where the
> > > CI prepares a set of packages with MD5 sums separately prepares a report
> > > of all new files and all files with changes to the headers.
> > >
> > > The RM then runs another tool that downloads the packages, verifies the
> > > MD5, signs with the PGP key (yes, the RM has to type in their password)
> > > and uploads it to the RC server.
> > >
> > > Then three folks run another tool that downloads the packages, verifies
> > > signatures, expands the source package, runs RAT, downloads an SCM tag,
> > > compares the source against the tag, runs the default ant or maven target,
> > > and prepares a report with the LICENSE and NOTICE files and headers of new
> > > files and changed headers and RAT output.
> > >
> > > As soon as three folks vote +1 and there are not more -1's, another tool
> > > is run to push it to the release server.
> > >
> > > Would this meet requirements and be acceptable?

From my limited ASF experience, I’d guess that this meets the Foundation’s requirements (viz the earlier URLs) and if your community’s OK with it why not. 72 hours IIRC is not mandated, its a guideline across many projects based on striking a balance between full consensus and fast releases.

> > > What if a machine did the downloading of packages, signature verification,
> > > RAT, SCM compare and build so the voters only need to review a report
> > > before voting. Would that also meet requirements and be acceptable?

> > > Thanks,
> > > -Alex

I have a personal script that does most of this for me for CouchDB, and assuming you’re on top of the commits coming through anyway, it seems “sufficient to meet criteria”. If everybody contributed to that script for a given project it could be a very comprehensive check.

However the bigger picture here is that the Foundation partly exists to provide a legal cushion for projects & their representatives. We have a number of ASF people who have experience of the need for that cushion, and as somebody who used to work for Telcos and Big Tech, I fully understand the need for that cushion.

I’m reluctant to pull all the feathers out of the cushion, only to find later that a crack-smoking team of opposing lawyers just pwned my house and put my family on the street. It’s speculation to say that removing all but the final Rubber Stamp +1 (I read the report, its sweet bro) is *definitely* legally sustainable in the face of determined opposition from for example Patent Trolls. The potentially increased risk is simply not quantifiable, esp IANAL etc.

Finally, for the “older ASFers” here. I get your concerns, and I’ve had enough big corp business experience to understand the continued need to keep that risk managed.

However I suspect that a large part of Cordova peoples’ concerns (and others) is that there is a foaming, cresting, evolving wave of open source out there, where hundreds of thousands of people surf and live on the bleeding edge of packages, across javascript, haskell, erlang, clojure and others, who are not afraid of a few incompatibilities along the way. Those people pushing the limits of what they can do are ones we should bring, and keep, on board.

We need to ensure that the ASF retains its pride of place for Superb Software, in this new mad crazy world, without compromising its principles. Whether this means refining and evolving the acceptable level of automation, continuing the vastly improved release process documentation, or something else, make no mistake — the single biggest risk to the Foundation’s long term existence is to be labelled a dinosaur — whether unfairly or not.

Brian, Joe, Alex, if you got this far, are you implying that a/the reason for the drop in release cadence for Cordova was as a result of release process difficulties? What can we do to help your project? Anything else?

A+
dch
--
Sent from my Couch



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

Re: Release Policy

[Brian LeRoux <b...@brian.io>]

If a computer performed the actions a human did the same objectives could
be reached. Furthermore some projects such as OpenOffice mentioned earlier
do not follow the policy. Finally, it was also mentioned in this very
thread that there was no legal finality to it. (Search for "end of story".)
Was that incorrect?


On Fri, May 23, 2014 at 2:39 PM, Jim Jagielski <ji...@jagunet.com> wrote:

> You're right... I'm not aware of much. In fact, I don't
> know that much either... I don't know much about history,
> don't know much biology; I don't know much about a science book
> and don't know much about the French I took.
>
> But I do know that I love you. And I know that if you love me, too,
> what a wonderful world this would be.
>
> On May 23, 2014, at 3:29 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > Just checking if you were aware, since you don't seem to be aware of
> much.
> >
> > On May 23, 2014 12:23 PM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> > How nice.
> >
> > On May 23, 2014, at 3:14 PM, Joe Bowser <bo...@gmail.com> wrote:
> >
> > >
> > > On May 23, 2014 11:47 AM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> > > >
> > > > This was discussed, at length, both on various mailing
> > > > lists as well as at the f2f rountable @ ApacheCon.
> > > >
> > >
> > > You are aware that people on this list didn't attend ApacheCon for
> either personal or professional reasons? Not that I want to ever see you
> personally given how miserable you are over e-mail.
> > >
> > > > I am sorry if such clarification isn't enough for you,
> > > > but, at the end of the day, that's your issue, not mine.
> > > > You may disagree with it, and you are welcome to do so,
> > > > but to claim that the justifications have been "meandering"
> > > > is both inaccurate and self-serving.
> > > >
> > > > On May 23, 2014, at 2:33 PM, Brian LeRoux <b...@brian.io> wrote:
> > > >
> > > > > Yes it is as JJ says as long as a vote happens the tools matter
> not. Though why the vote has to happen is yet to be clarified other than
> meandering justifications.
> > > > >
> > > > > On May 23, 2014 11:56 AM, "Alex Harui" <ah...@adobe.com> wrote:
> > > > > This current proposal no longer requires 72 hour voting.  To me,
> this
> > > > > means that we could eventually automate releasing to the point
> where the
> > > > > CI prepares a set of packages with MD5 sums separately prepares a
> report
> > > > > of all new files and all files with changes to the headers.
> > > > >
> > > > > The RM then runs another tool that downloads the packages,
> verifies the
> > > > > MD5, signs with the PGP key (yes, the RM has to type in their
> password)
> > > > > and uploads it to the RC server.
> > > > >
> > > > > Then three folks run another tool that downloads the packages,
> verifies
> > > > > signatures, expands the source package, runs RAT, downloads an SCM
> tag,
> > > > > compares the source against the tag, runs the default ant or maven
> target,
> > > > > and prepares a report with the LICENSE and NOTICE files and
> headers of new
> > > > > files and changed headers and RAT output.
> > > > >
> > > > > As soon as three folks vote +1 and there are not more -1's,
> another tool
> > > > > is run to push it to the release server.
> > > > >
> > > > > Would this meet requirements and be acceptable?
> > > > >
> > > > > What if a machine did the downloading of packages, signature
> verification,
> > > > > RAT, SCM compare and build so the voters only need to review a
> report
> > > > > before voting.  Would that also meet requirements and be
> acceptable?
> > > > >
> > > > > Thanks,
> > > > > -Alex
> > > > >
> > > > > On 5/23/14 8:43 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
> > > > >
> > > > > >People perform releases. They can use whatever tools
> > > > > >they want, but at the end, the only validation check
> > > > > >that really matters are those PMC members who test,
> > > > > >validate and +1 the release.
> > > > > >
> > > > > >For example, let's say that there is a codebase that
> > > > > >doesn't pass some test, but get's the required 3 +1s
> > > > > >for release and the RM doesn't pull it. Even though
> > > > > >according to the CI (or whatever) it's "not a release"
> > > > > >(it failed), as far as the PMC and the ASF is concerned,
> > > > > >it IS a release.
> > > > > >
> > > > > >Conversely, no matter what a CI may test, package and
> > > > > >drop off somewhere, if it's not voted on, it's not
> > > > > >a release.
> > > > > >
> > > > > >On May 23, 2014, at 11:33 AM, Brian LeRoux <b...@brian.io> wrote:
> > > > > >
> > > > > >> C'mon Sebb. This is circular false logic.
> > > > > >>
> > > > > >> On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com> wrote:
> > > > > >> On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
> > > > > >> > @mark agree, there are many layers to the stated legal
> perception and
> > > > > >>indeed
> > > > > >> > most other OSS projects do not require a VOTE. It was
> communicated to
> > > > > >>me
> > > > > >> > that the VOTE specifically mitigated risk to the releasing
> individual
> > > > > >> > (publishing artifacts to ./dist). This, and human error, are
> > > > > >>mitigated by
> > > > > >> > not using humans to perform those actions susceptible to
> human error.
> > > > > >>That
> > > > > >> > is the point of a CI system and automated builds. All the
> actions of a
> > > > > >> > release could be done by a machine and ensuring the policy
> will allow
> > > > > >>that
> > > > > >> > is what I'm looking for.
> > > > > >>
> > > > > >> However, the CI and automated build systems are created by
> fallible
> > > > > >>humans.
> > > > > >>
> > > > > >> This is why it is important to ensure that the release vote
> contains
> > > > > >> sufficient details for an independent check of the source
> release
> > > > > >> contents against the SCM tag.
> > > > > >>
> > > > > >> >
> > > > > >> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <
> struberg@yahoo.de>
> > > > > >>wrote:
> > > > > >> >>
> > > > > >> >> Brian, we only specifically talked about whether we should be
> > > > > >>allowed to
> > > > > >> >> give_intermediate_ build artifacts like nightly builds, etc
> to
> > > > > >>interested
> > > > > >> >> people. I personally find it a bit too restrictive to not
> allow to
> > > > > >>publish
> > > > > >> >> those for user testing. We (the foundation) already do this
> via our
> > > > > >> >> snapshots maven repos...
> > > > > >> >>
> > > > > >> >> And there are also different layers of 'legal'. There is no
> law in
> > > > > >>the US
> > > > > >> >> nor otherwhere in the world who requires a VOTE before an
> opensource
> > > > > >> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
> > > > > >> >>
> > > > > >> >> BUT: it is an ASF policy and thus binding for all our
> projects to
> > > > > >>VOTE on
> > > > > >> >> releases.
> > > > > >> >> And it is a really good one as it increases the technical
> and legal
> > > > > >> >> quality of our products! It's really a good thing to have
> 10+ people
> > > > > >>looking
> > > > > >> >> at a release and e.g. discovering that a file has the wrong
> license
> > > > > >>and
> > > > > >> >> should get removed again for example. And of course it helps
> > > > > >>reducing the
> > > > > >> >> risk from getting sued because we obviously try to minimize
> human
> > > > > >>errors.
> > > > > >> >>
> > > > > >> >> @Shane I'm not sure how many ASF members are subscribed to
> the legal
> > > > > >>list,
> > > > > >> >> maybe it is enough if we just rise awareness.
> > > > > >> >>
> > > > > >> >> LieGrue,
> > > > > >> >> strub
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io>
> wrote:
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> "But the point already got covered and answered dozens of
> times imo.
> > > > > >>The
> > > > > >> >> answer is that the ALv2 protects the foundation and also the
> release
> > > > > >>manager
> > > > > >> >> already for all bona fides cases. End of story."
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> Interesting for myself to note that it was communicated very
> > > > > >>directly to
> > > > > >> >> Cordova that this *was not* the case. Votes are a necessary
> > > > > >>component for a
> > > > > >> >> valid (aka legal) release. Also interesting for me to
> discover in
> > > > > >>this
> > > > > >> >> thread that the release policy is not adhered to by all ASF
> > > > > >>projects. We
> > > > > >> >> were lead to believe the rules are immutable, all projects
> obey
> > > > > >>them. End of
> > > > > >> >> story.
> > > > > >> >>
> > > > > >> >> I am dismayed to discover this is not the case and Cordova
> was
> > > > > >>singled
> > > > > >> >> out.
> > > > > >> >>
> > > > > >> >> However, clarity here is a great starting to amending the
> rules, and
> > > > > >>I
> > > > > >> >> recognize this effort is not forum for that. My perspective:
> the
> > > > > >>vote is a
> > > > > >> >> SHOULD and most certainly SHA verifciation SHOULD be the job
> of a
> > > > > >>computer
> > > > > >> >> (aka CI system) and not a human and I am very happy to hear
> there is
> > > > > >> >> precedent for this with other projects.
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >
> > > > > >>
> > > > > >>
> ---------------------------------------------------------------------
> > > > > >> 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
> > > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > 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
> > > >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>

Re: Release Policy

[Jim Jagielski <ji...@jaguNET.com>]

You're right... I'm not aware of much. In fact, I don't
know that much either... I don't know much about history,
don't know much biology; I don't know much about a science book
and don't know much about the French I took.

But I do know that I love you. And I know that if you love me, too,
what a wonderful world this would be.

On May 23, 2014, at 3:29 PM, Joe Bowser <bo...@gmail.com> wrote:

> Just checking if you were aware, since you don't seem to be aware of much.
> 
> On May 23, 2014 12:23 PM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> How nice.
> 
> On May 23, 2014, at 3:14 PM, Joe Bowser <bo...@gmail.com> wrote:
> 
> >
> > On May 23, 2014 11:47 AM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> > >
> > > This was discussed, at length, both on various mailing
> > > lists as well as at the f2f rountable @ ApacheCon.
> > >
> >
> > You are aware that people on this list didn't attend ApacheCon for either personal or professional reasons? Not that I want to ever see you personally given how miserable you are over e-mail.
> >
> > > I am sorry if such clarification isn't enough for you,
> > > but, at the end of the day, that's your issue, not mine.
> > > You may disagree with it, and you are welcome to do so,
> > > but to claim that the justifications have been "meandering"
> > > is both inaccurate and self-serving.
> > >
> > > On May 23, 2014, at 2:33 PM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > Yes it is as JJ says as long as a vote happens the tools matter not. Though why the vote has to happen is yet to be clarified other than meandering justifications.
> > > >
> > > > On May 23, 2014 11:56 AM, "Alex Harui" <ah...@adobe.com> wrote:
> > > > This current proposal no longer requires 72 hour voting.  To me, this
> > > > means that we could eventually automate releasing to the point where the
> > > > CI prepares a set of packages with MD5 sums separately prepares a report
> > > > of all new files and all files with changes to the headers.
> > > >
> > > > The RM then runs another tool that downloads the packages, verifies the
> > > > MD5, signs with the PGP key (yes, the RM has to type in their password)
> > > > and uploads it to the RC server.
> > > >
> > > > Then three folks run another tool that downloads the packages, verifies
> > > > signatures, expands the source package, runs RAT, downloads an SCM tag,
> > > > compares the source against the tag, runs the default ant or maven target,
> > > > and prepares a report with the LICENSE and NOTICE files and headers of new
> > > > files and changed headers and RAT output.
> > > >
> > > > As soon as three folks vote +1 and there are not more -1's, another tool
> > > > is run to push it to the release server.
> > > >
> > > > Would this meet requirements and be acceptable?
> > > >
> > > > What if a machine did the downloading of packages, signature verification,
> > > > RAT, SCM compare and build so the voters only need to review a report
> > > > before voting.  Would that also meet requirements and be acceptable?
> > > >
> > > > Thanks,
> > > > -Alex
> > > >
> > > > On 5/23/14 8:43 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
> > > >
> > > > >People perform releases. They can use whatever tools
> > > > >they want, but at the end, the only validation check
> > > > >that really matters are those PMC members who test,
> > > > >validate and +1 the release.
> > > > >
> > > > >For example, let's say that there is a codebase that
> > > > >doesn't pass some test, but get's the required 3 +1s
> > > > >for release and the RM doesn't pull it. Even though
> > > > >according to the CI (or whatever) it's "not a release"
> > > > >(it failed), as far as the PMC and the ASF is concerned,
> > > > >it IS a release.
> > > > >
> > > > >Conversely, no matter what a CI may test, package and
> > > > >drop off somewhere, if it's not voted on, it's not
> > > > >a release.
> > > > >
> > > > >On May 23, 2014, at 11:33 AM, Brian LeRoux <b...@brian.io> wrote:
> > > > >
> > > > >> C'mon Sebb. This is circular false logic.
> > > > >>
> > > > >> On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com> wrote:
> > > > >> On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
> > > > >> > @mark agree, there are many layers to the stated legal perception and
> > > > >>indeed
> > > > >> > most other OSS projects do not require a VOTE. It was communicated to
> > > > >>me
> > > > >> > that the VOTE specifically mitigated risk to the releasing individual
> > > > >> > (publishing artifacts to ./dist). This, and human error, are
> > > > >>mitigated by
> > > > >> > not using humans to perform those actions susceptible to human error.
> > > > >>That
> > > > >> > is the point of a CI system and automated builds. All the actions of a
> > > > >> > release could be done by a machine and ensuring the policy will allow
> > > > >>that
> > > > >> > is what I'm looking for.
> > > > >>
> > > > >> However, the CI and automated build systems are created by fallible
> > > > >>humans.
> > > > >>
> > > > >> This is why it is important to ensure that the release vote contains
> > > > >> sufficient details for an independent check of the source release
> > > > >> contents against the SCM tag.
> > > > >>
> > > > >> >
> > > > >> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de>
> > > > >>wrote:
> > > > >> >>
> > > > >> >> Brian, we only specifically talked about whether we should be
> > > > >>allowed to
> > > > >> >> give_intermediate_ build artifacts like nightly builds, etc to
> > > > >>interested
> > > > >> >> people. I personally find it a bit too restrictive to not allow to
> > > > >>publish
> > > > >> >> those for user testing. We (the foundation) already do this via our
> > > > >> >> snapshots maven repos...
> > > > >> >>
> > > > >> >> And there are also different layers of 'legal'. There is no law in
> > > > >>the US
> > > > >> >> nor otherwhere in the world who requires a VOTE before an opensource
> > > > >> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
> > > > >> >>
> > > > >> >> BUT: it is an ASF policy and thus binding for all our projects to
> > > > >>VOTE on
> > > > >> >> releases.
> > > > >> >> And it is a really good one as it increases the technical and legal
> > > > >> >> quality of our products! It's really a good thing to have 10+ people
> > > > >>looking
> > > > >> >> at a release and e.g. discovering that a file has the wrong license
> > > > >>and
> > > > >> >> should get removed again for example. And of course it helps
> > > > >>reducing the
> > > > >> >> risk from getting sued because we obviously try to minimize human
> > > > >>errors.
> > > > >> >>
> > > > >> >> @Shane I'm not sure how many ASF members are subscribed to the legal
> > > > >>list,
> > > > >> >> maybe it is enough if we just rise awareness.
> > > > >> >>
> > > > >> >> LieGrue,
> > > > >> >> strub
> > > > >> >>
> > > > >> >>
> > > > >> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> "But the point already got covered and answered dozens of times imo.
> > > > >>The
> > > > >> >> answer is that the ALv2 protects the foundation and also the release
> > > > >>manager
> > > > >> >> already for all bona fides cases. End of story."
> > > > >> >>
> > > > >> >>
> > > > >> >> Interesting for myself to note that it was communicated very
> > > > >>directly to
> > > > >> >> Cordova that this *was not* the case. Votes are a necessary
> > > > >>component for a
> > > > >> >> valid (aka legal) release. Also interesting for me to discover in
> > > > >>this
> > > > >> >> thread that the release policy is not adhered to by all ASF
> > > > >>projects. We
> > > > >> >> were lead to believe the rules are immutable, all projects obey
> > > > >>them. End of
> > > > >> >> story.
> > > > >> >>
> > > > >> >> I am dismayed to discover this is not the case and Cordova was
> > > > >>singled
> > > > >> >> out.
> > > > >> >>
> > > > >> >> However, clarity here is a great starting to amending the rules, and
> > > > >>I
> > > > >> >> recognize this effort is not forum for that. My perspective: the
> > > > >>vote is a
> > > > >> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
> > > > >>computer
> > > > >> >> (aka CI system) and not a human and I am very happy to hear there is
> > > > >> >> precedent for this with other projects.
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >
> > > > >>
> > > > >> ---------------------------------------------------------------------
> > > > >> 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
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
> 
> 
> ---------------------------------------------------------------------
> 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

Re: Release Policy

[Joe Bowser <bo...@gmail.com>]

Just checking if you were aware, since you don't seem to be aware of much.
On May 23, 2014 12:23 PM, "Jim Jagielski" <ji...@jagunet.com> wrote:

> How nice.
>
> On May 23, 2014, at 3:14 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> >
> > On May 23, 2014 11:47 AM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> > >
> > > This was discussed, at length, both on various mailing
> > > lists as well as at the f2f rountable @ ApacheCon.
> > >
> >
> > You are aware that people on this list didn't attend ApacheCon for
> either personal or professional reasons? Not that I want to ever see you
> personally given how miserable you are over e-mail.
> >
> > > I am sorry if such clarification isn't enough for you,
> > > but, at the end of the day, that's your issue, not mine.
> > > You may disagree with it, and you are welcome to do so,
> > > but to claim that the justifications have been "meandering"
> > > is both inaccurate and self-serving.
> > >
> > > On May 23, 2014, at 2:33 PM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > Yes it is as JJ says as long as a vote happens the tools matter not.
> Though why the vote has to happen is yet to be clarified other than
> meandering justifications.
> > > >
> > > > On May 23, 2014 11:56 AM, "Alex Harui" <ah...@adobe.com> wrote:
> > > > This current proposal no longer requires 72 hour voting.  To me, this
> > > > means that we could eventually automate releasing to the point where
> the
> > > > CI prepares a set of packages with MD5 sums separately prepares a
> report
> > > > of all new files and all files with changes to the headers.
> > > >
> > > > The RM then runs another tool that downloads the packages, verifies
> the
> > > > MD5, signs with the PGP key (yes, the RM has to type in their
> password)
> > > > and uploads it to the RC server.
> > > >
> > > > Then three folks run another tool that downloads the packages,
> verifies
> > > > signatures, expands the source package, runs RAT, downloads an SCM
> tag,
> > > > compares the source against the tag, runs the default ant or maven
> target,
> > > > and prepares a report with the LICENSE and NOTICE files and headers
> of new
> > > > files and changed headers and RAT output.
> > > >
> > > > As soon as three folks vote +1 and there are not more -1's, another
> tool
> > > > is run to push it to the release server.
> > > >
> > > > Would this meet requirements and be acceptable?
> > > >
> > > > What if a machine did the downloading of packages, signature
> verification,
> > > > RAT, SCM compare and build so the voters only need to review a report
> > > > before voting.  Would that also meet requirements and be acceptable?
> > > >
> > > > Thanks,
> > > > -Alex
> > > >
> > > > On 5/23/14 8:43 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
> > > >
> > > > >People perform releases. They can use whatever tools
> > > > >they want, but at the end, the only validation check
> > > > >that really matters are those PMC members who test,
> > > > >validate and +1 the release.
> > > > >
> > > > >For example, let's say that there is a codebase that
> > > > >doesn't pass some test, but get's the required 3 +1s
> > > > >for release and the RM doesn't pull it. Even though
> > > > >according to the CI (or whatever) it's "not a release"
> > > > >(it failed), as far as the PMC and the ASF is concerned,
> > > > >it IS a release.
> > > > >
> > > > >Conversely, no matter what a CI may test, package and
> > > > >drop off somewhere, if it's not voted on, it's not
> > > > >a release.
> > > > >
> > > > >On May 23, 2014, at 11:33 AM, Brian LeRoux <b...@brian.io> wrote:
> > > > >
> > > > >> C'mon Sebb. This is circular false logic.
> > > > >>
> > > > >> On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com> wrote:
> > > > >> On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
> > > > >> > @mark agree, there are many layers to the stated legal
> perception and
> > > > >>indeed
> > > > >> > most other OSS projects do not require a VOTE. It was
> communicated to
> > > > >>me
> > > > >> > that the VOTE specifically mitigated risk to the releasing
> individual
> > > > >> > (publishing artifacts to ./dist). This, and human error, are
> > > > >>mitigated by
> > > > >> > not using humans to perform those actions susceptible to human
> error.
> > > > >>That
> > > > >> > is the point of a CI system and automated builds. All the
> actions of a
> > > > >> > release could be done by a machine and ensuring the policy will
> allow
> > > > >>that
> > > > >> > is what I'm looking for.
> > > > >>
> > > > >> However, the CI and automated build systems are created by
> fallible
> > > > >>humans.
> > > > >>
> > > > >> This is why it is important to ensure that the release vote
> contains
> > > > >> sufficient details for an independent check of the source release
> > > > >> contents against the SCM tag.
> > > > >>
> > > > >> >
> > > > >> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <
> struberg@yahoo.de>
> > > > >>wrote:
> > > > >> >>
> > > > >> >> Brian, we only specifically talked about whether we should be
> > > > >>allowed to
> > > > >> >> give_intermediate_ build artifacts like nightly builds, etc to
> > > > >>interested
> > > > >> >> people. I personally find it a bit too restrictive to not
> allow to
> > > > >>publish
> > > > >> >> those for user testing. We (the foundation) already do this
> via our
> > > > >> >> snapshots maven repos...
> > > > >> >>
> > > > >> >> And there are also different layers of 'legal'. There is no
> law in
> > > > >>the US
> > > > >> >> nor otherwhere in the world who requires a VOTE before an
> opensource
> > > > >> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
> > > > >> >>
> > > > >> >> BUT: it is an ASF policy and thus binding for all our projects
> to
> > > > >>VOTE on
> > > > >> >> releases.
> > > > >> >> And it is a really good one as it increases the technical and
> legal
> > > > >> >> quality of our products! It's really a good thing to have 10+
> people
> > > > >>looking
> > > > >> >> at a release and e.g. discovering that a file has the wrong
> license
> > > > >>and
> > > > >> >> should get removed again for example. And of course it helps
> > > > >>reducing the
> > > > >> >> risk from getting sued because we obviously try to minimize
> human
> > > > >>errors.
> > > > >> >>
> > > > >> >> @Shane I'm not sure how many ASF members are subscribed to the
> legal
> > > > >>list,
> > > > >> >> maybe it is enough if we just rise awareness.
> > > > >> >>
> > > > >> >> LieGrue,
> > > > >> >> strub
> > > > >> >>
> > > > >> >>
> > > > >> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io>
> wrote:
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> "But the point already got covered and answered dozens of
> times imo.
> > > > >>The
> > > > >> >> answer is that the ALv2 protects the foundation and also the
> release
> > > > >>manager
> > > > >> >> already for all bona fides cases. End of story."
> > > > >> >>
> > > > >> >>
> > > > >> >> Interesting for myself to note that it was communicated very
> > > > >>directly to
> > > > >> >> Cordova that this *was not* the case. Votes are a necessary
> > > > >>component for a
> > > > >> >> valid (aka legal) release. Also interesting for me to discover
> in
> > > > >>this
> > > > >> >> thread that the release policy is not adhered to by all ASF
> > > > >>projects. We
> > > > >> >> were lead to believe the rules are immutable, all projects obey
> > > > >>them. End of
> > > > >> >> story.
> > > > >> >>
> > > > >> >> I am dismayed to discover this is not the case and Cordova was
> > > > >>singled
> > > > >> >> out.
> > > > >> >>
> > > > >> >> However, clarity here is a great starting to amending the
> rules, and
> > > > >>I
> > > > >> >> recognize this effort is not forum for that. My perspective:
> the
> > > > >>vote is a
> > > > >> >> SHOULD and most certainly SHA verifciation SHOULD be the job
> of a
> > > > >>computer
> > > > >> >> (aka CI system) and not a human and I am very happy to hear
> there is
> > > > >> >> precedent for this with other projects.
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >
> > > > >>
> > > > >>
> ---------------------------------------------------------------------
> > > > >> 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
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

Re: Release Policy

[Jim Jagielski <ji...@jaguNET.com>]

How nice.

On May 23, 2014, at 3:14 PM, Joe Bowser <bo...@gmail.com> wrote:

> 
> On May 23, 2014 11:47 AM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> >
> > This was discussed, at length, both on various mailing
> > lists as well as at the f2f rountable @ ApacheCon.
> >
> 
> You are aware that people on this list didn't attend ApacheCon for either personal or professional reasons? Not that I want to ever see you personally given how miserable you are over e-mail.
> 
> > I am sorry if such clarification isn't enough for you,
> > but, at the end of the day, that's your issue, not mine.
> > You may disagree with it, and you are welcome to do so,
> > but to claim that the justifications have been "meandering"
> > is both inaccurate and self-serving.
> >
> > On May 23, 2014, at 2:33 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > Yes it is as JJ says as long as a vote happens the tools matter not. Though why the vote has to happen is yet to be clarified other than meandering justifications.
> > >
> > > On May 23, 2014 11:56 AM, "Alex Harui" <ah...@adobe.com> wrote:
> > > This current proposal no longer requires 72 hour voting.  To me, this
> > > means that we could eventually automate releasing to the point where the
> > > CI prepares a set of packages with MD5 sums separately prepares a report
> > > of all new files and all files with changes to the headers.
> > >
> > > The RM then runs another tool that downloads the packages, verifies the
> > > MD5, signs with the PGP key (yes, the RM has to type in their password)
> > > and uploads it to the RC server.
> > >
> > > Then three folks run another tool that downloads the packages, verifies
> > > signatures, expands the source package, runs RAT, downloads an SCM tag,
> > > compares the source against the tag, runs the default ant or maven target,
> > > and prepares a report with the LICENSE and NOTICE files and headers of new
> > > files and changed headers and RAT output.
> > >
> > > As soon as three folks vote +1 and there are not more -1's, another tool
> > > is run to push it to the release server.
> > >
> > > Would this meet requirements and be acceptable?
> > >
> > > What if a machine did the downloading of packages, signature verification,
> > > RAT, SCM compare and build so the voters only need to review a report
> > > before voting.  Would that also meet requirements and be acceptable?
> > >
> > > Thanks,
> > > -Alex
> > >
> > > On 5/23/14 8:43 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
> > >
> > > >People perform releases. They can use whatever tools
> > > >they want, but at the end, the only validation check
> > > >that really matters are those PMC members who test,
> > > >validate and +1 the release.
> > > >
> > > >For example, let's say that there is a codebase that
> > > >doesn't pass some test, but get's the required 3 +1s
> > > >for release and the RM doesn't pull it. Even though
> > > >according to the CI (or whatever) it's "not a release"
> > > >(it failed), as far as the PMC and the ASF is concerned,
> > > >it IS a release.
> > > >
> > > >Conversely, no matter what a CI may test, package and
> > > >drop off somewhere, if it's not voted on, it's not
> > > >a release.
> > > >
> > > >On May 23, 2014, at 11:33 AM, Brian LeRoux <b...@brian.io> wrote:
> > > >
> > > >> C'mon Sebb. This is circular false logic.
> > > >>
> > > >> On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com> wrote:
> > > >> On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
> > > >> > @mark agree, there are many layers to the stated legal perception and
> > > >>indeed
> > > >> > most other OSS projects do not require a VOTE. It was communicated to
> > > >>me
> > > >> > that the VOTE specifically mitigated risk to the releasing individual
> > > >> > (publishing artifacts to ./dist). This, and human error, are
> > > >>mitigated by
> > > >> > not using humans to perform those actions susceptible to human error.
> > > >>That
> > > >> > is the point of a CI system and automated builds. All the actions of a
> > > >> > release could be done by a machine and ensuring the policy will allow
> > > >>that
> > > >> > is what I'm looking for.
> > > >>
> > > >> However, the CI and automated build systems are created by fallible
> > > >>humans.
> > > >>
> > > >> This is why it is important to ensure that the release vote contains
> > > >> sufficient details for an independent check of the source release
> > > >> contents against the SCM tag.
> > > >>
> > > >> >
> > > >> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de>
> > > >>wrote:
> > > >> >>
> > > >> >> Brian, we only specifically talked about whether we should be
> > > >>allowed to
> > > >> >> give_intermediate_ build artifacts like nightly builds, etc to
> > > >>interested
> > > >> >> people. I personally find it a bit too restrictive to not allow to
> > > >>publish
> > > >> >> those for user testing. We (the foundation) already do this via our
> > > >> >> snapshots maven repos...
> > > >> >>
> > > >> >> And there are also different layers of 'legal'. There is no law in
> > > >>the US
> > > >> >> nor otherwhere in the world who requires a VOTE before an opensource
> > > >> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
> > > >> >>
> > > >> >> BUT: it is an ASF policy and thus binding for all our projects to
> > > >>VOTE on
> > > >> >> releases.
> > > >> >> And it is a really good one as it increases the technical and legal
> > > >> >> quality of our products! It's really a good thing to have 10+ people
> > > >>looking
> > > >> >> at a release and e.g. discovering that a file has the wrong license
> > > >>and
> > > >> >> should get removed again for example. And of course it helps
> > > >>reducing the
> > > >> >> risk from getting sued because we obviously try to minimize human
> > > >>errors.
> > > >> >>
> > > >> >> @Shane I'm not sure how many ASF members are subscribed to the legal
> > > >>list,
> > > >> >> maybe it is enough if we just rise awareness.
> > > >> >>
> > > >> >> LieGrue,
> > > >> >> strub
> > > >> >>
> > > >> >>
> > > >> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> "But the point already got covered and answered dozens of times imo.
> > > >>The
> > > >> >> answer is that the ALv2 protects the foundation and also the release
> > > >>manager
> > > >> >> already for all bona fides cases. End of story."
> > > >> >>
> > > >> >>
> > > >> >> Interesting for myself to note that it was communicated very
> > > >>directly to
> > > >> >> Cordova that this *was not* the case. Votes are a necessary
> > > >>component for a
> > > >> >> valid (aka legal) release. Also interesting for me to discover in
> > > >>this
> > > >> >> thread that the release policy is not adhered to by all ASF
> > > >>projects. We
> > > >> >> were lead to believe the rules are immutable, all projects obey
> > > >>them. End of
> > > >> >> story.
> > > >> >>
> > > >> >> I am dismayed to discover this is not the case and Cordova was
> > > >>singled
> > > >> >> out.
> > > >> >>
> > > >> >> However, clarity here is a great starting to amending the rules, and
> > > >>I
> > > >> >> recognize this effort is not forum for that. My perspective: the
> > > >>vote is a
> > > >> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
> > > >>computer
> > > >> >> (aka CI system) and not a human and I am very happy to hear there is
> > > >> >> precedent for this with other projects.
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> 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
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >


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

Re: Release Policy

[Joe Bowser <bo...@gmail.com>]

On May 23, 2014 11:47 AM, "Jim Jagielski" <ji...@jagunet.com> wrote:
>
> This was discussed, at length, both on various mailing
> lists as well as at the f2f rountable @ ApacheCon.
>

You are aware that people on this list didn't attend ApacheCon for either
personal or professional reasons? Not that I want to ever see you
personally given how miserable you are over e-mail.

> I am sorry if such clarification isn't enough for you,
> but, at the end of the day, that's your issue, not mine.
> You may disagree with it, and you are welcome to do so,
> but to claim that the justifications have been "meandering"
> is both inaccurate and self-serving.
>
> On May 23, 2014, at 2:33 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > Yes it is as JJ says as long as a vote happens the tools matter not.
Though why the vote has to happen is yet to be clarified other than
meandering justifications.
> >
> > On May 23, 2014 11:56 AM, "Alex Harui" <ah...@adobe.com> wrote:
> > This current proposal no longer requires 72 hour voting.  To me, this
> > means that we could eventually automate releasing to the point where the
> > CI prepares a set of packages with MD5 sums separately prepares a report
> > of all new files and all files with changes to the headers.
> >
> > The RM then runs another tool that downloads the packages, verifies the
> > MD5, signs with the PGP key (yes, the RM has to type in their password)
> > and uploads it to the RC server.
> >
> > Then three folks run another tool that downloads the packages, verifies
> > signatures, expands the source package, runs RAT, downloads an SCM tag,
> > compares the source against the tag, runs the default ant or maven
target,
> > and prepares a report with the LICENSE and NOTICE files and headers of
new
> > files and changed headers and RAT output.
> >
> > As soon as three folks vote +1 and there are not more -1's, another tool
> > is run to push it to the release server.
> >
> > Would this meet requirements and be acceptable?
> >
> > What if a machine did the downloading of packages, signature
verification,
> > RAT, SCM compare and build so the voters only need to review a report
> > before voting.  Would that also meet requirements and be acceptable?
> >
> > Thanks,
> > -Alex
> >
> > On 5/23/14 8:43 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
> >
> > >People perform releases. They can use whatever tools
> > >they want, but at the end, the only validation check
> > >that really matters are those PMC members who test,
> > >validate and +1 the release.
> > >
> > >For example, let's say that there is a codebase that
> > >doesn't pass some test, but get's the required 3 +1s
> > >for release and the RM doesn't pull it. Even though
> > >according to the CI (or whatever) it's "not a release"
> > >(it failed), as far as the PMC and the ASF is concerned,
> > >it IS a release.
> > >
> > >Conversely, no matter what a CI may test, package and
> > >drop off somewhere, if it's not voted on, it's not
> > >a release.
> > >
> > >On May 23, 2014, at 11:33 AM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > >> C'mon Sebb. This is circular false logic.
> > >>
> > >> On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com> wrote:
> > >> On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
> > >> > @mark agree, there are many layers to the stated legal perception
and
> > >>indeed
> > >> > most other OSS projects do not require a VOTE. It was communicated
to
> > >>me
> > >> > that the VOTE specifically mitigated risk to the releasing
individual
> > >> > (publishing artifacts to ./dist). This, and human error, are
> > >>mitigated by
> > >> > not using humans to perform those actions susceptible to human
error.
> > >>That
> > >> > is the point of a CI system and automated builds. All the actions
of a
> > >> > release could be done by a machine and ensuring the policy will
allow
> > >>that
> > >> > is what I'm looking for.
> > >>
> > >> However, the CI and automated build systems are created by fallible
> > >>humans.
> > >>
> > >> This is why it is important to ensure that the release vote contains
> > >> sufficient details for an independent check of the source release
> > >> contents against the SCM tag.
> > >>
> > >> >
> > >> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de>
> > >>wrote:
> > >> >>
> > >> >> Brian, we only specifically talked about whether we should be
> > >>allowed to
> > >> >> give_intermediate_ build artifacts like nightly builds, etc to
> > >>interested
> > >> >> people. I personally find it a bit too restrictive to not allow to
> > >>publish
> > >> >> those for user testing. We (the foundation) already do this via
our
> > >> >> snapshots maven repos...
> > >> >>
> > >> >> And there are also different layers of 'legal'. There is no law in
> > >>the US
> > >> >> nor otherwhere in the world who requires a VOTE before an
opensource
> > >> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
> > >> >>
> > >> >> BUT: it is an ASF policy and thus binding for all our projects to
> > >>VOTE on
> > >> >> releases.
> > >> >> And it is a really good one as it increases the technical and
legal
> > >> >> quality of our products! It's really a good thing to have 10+
people
> > >>looking
> > >> >> at a release and e.g. discovering that a file has the wrong
license
> > >>and
> > >> >> should get removed again for example. And of course it helps
> > >>reducing the
> > >> >> risk from getting sued because we obviously try to minimize human
> > >>errors.
> > >> >>
> > >> >> @Shane I'm not sure how many ASF members are subscribed to the
legal
> > >>list,
> > >> >> maybe it is enough if we just rise awareness.
> > >> >>
> > >> >> LieGrue,
> > >> >> strub
> > >> >>
> > >> >>
> > >> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> "But the point already got covered and answered dozens of times
imo.
> > >>The
> > >> >> answer is that the ALv2 protects the foundation and also the
release
> > >>manager
> > >> >> already for all bona fides cases. End of story."
> > >> >>
> > >> >>
> > >> >> Interesting for myself to note that it was communicated very
> > >>directly to
> > >> >> Cordova that this *was not* the case. Votes are a necessary
> > >>component for a
> > >> >> valid (aka legal) release. Also interesting for me to discover in
> > >>this
> > >> >> thread that the release policy is not adhered to by all ASF
> > >>projects. We
> > >> >> were lead to believe the rules are immutable, all projects obey
> > >>them. End of
> > >> >> story.
> > >> >>
> > >> >> I am dismayed to discover this is not the case and Cordova was
> > >>singled
> > >> >> out.
> > >> >>
> > >> >> However, clarity here is a great starting to amending the rules,
and
> > >>I
> > >> >> recognize this effort is not forum for that. My perspective: the
> > >>vote is a
> > >> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
> > >>computer
> > >> >> (aka CI system) and not a human and I am very happy to hear there
is
> > >> >> precedent for this with other projects.
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>

Re: Release Policy

[Jim Jagielski <ji...@jaguNET.com>]

This was discussed, at length, both on various mailing
lists as well as at the f2f rountable @ ApacheCon.

I am sorry if such clarification isn't enough for you,
but, at the end of the day, that's your issue, not mine.
You may disagree with it, and you are welcome to do so,
but to claim that the justifications have been "meandering"
is both inaccurate and self-serving.

On May 23, 2014, at 2:33 PM, Brian LeRoux <b...@brian.io> wrote:

> Yes it is as JJ says as long as a vote happens the tools matter not. Though why the vote has to happen is yet to be clarified other than meandering justifications.
> 
> On May 23, 2014 11:56 AM, "Alex Harui" <ah...@adobe.com> wrote:
> This current proposal no longer requires 72 hour voting.  To me, this
> means that we could eventually automate releasing to the point where the
> CI prepares a set of packages with MD5 sums separately prepares a report
> of all new files and all files with changes to the headers.
> 
> The RM then runs another tool that downloads the packages, verifies the
> MD5, signs with the PGP key (yes, the RM has to type in their password)
> and uploads it to the RC server.
> 
> Then three folks run another tool that downloads the packages, verifies
> signatures, expands the source package, runs RAT, downloads an SCM tag,
> compares the source against the tag, runs the default ant or maven target,
> and prepares a report with the LICENSE and NOTICE files and headers of new
> files and changed headers and RAT output.
> 
> As soon as three folks vote +1 and there are not more -1's, another tool
> is run to push it to the release server.
> 
> Would this meet requirements and be acceptable?
> 
> What if a machine did the downloading of packages, signature verification,
> RAT, SCM compare and build so the voters only need to review a report
> before voting.  Would that also meet requirements and be acceptable?
> 
> Thanks,
> -Alex
> 
> On 5/23/14 8:43 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
> 
> >People perform releases. They can use whatever tools
> >they want, but at the end, the only validation check
> >that really matters are those PMC members who test,
> >validate and +1 the release.
> >
> >For example, let's say that there is a codebase that
> >doesn't pass some test, but get's the required 3 +1s
> >for release and the RM doesn't pull it. Even though
> >according to the CI (or whatever) it's "not a release"
> >(it failed), as far as the PMC and the ASF is concerned,
> >it IS a release.
> >
> >Conversely, no matter what a CI may test, package and
> >drop off somewhere, if it's not voted on, it's not
> >a release.
> >
> >On May 23, 2014, at 11:33 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> C'mon Sebb. This is circular false logic.
> >>
> >> On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com> wrote:
> >> On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
> >> > @mark agree, there are many layers to the stated legal perception and
> >>indeed
> >> > most other OSS projects do not require a VOTE. It was communicated to
> >>me
> >> > that the VOTE specifically mitigated risk to the releasing individual
> >> > (publishing artifacts to ./dist). This, and human error, are
> >>mitigated by
> >> > not using humans to perform those actions susceptible to human error.
> >>That
> >> > is the point of a CI system and automated builds. All the actions of a
> >> > release could be done by a machine and ensuring the policy will allow
> >>that
> >> > is what I'm looking for.
> >>
> >> However, the CI and automated build systems are created by fallible
> >>humans.
> >>
> >> This is why it is important to ensure that the release vote contains
> >> sufficient details for an independent check of the source release
> >> contents against the SCM tag.
> >>
> >> >
> >> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de>
> >>wrote:
> >> >>
> >> >> Brian, we only specifically talked about whether we should be
> >>allowed to
> >> >> give_intermediate_ build artifacts like nightly builds, etc to
> >>interested
> >> >> people. I personally find it a bit too restrictive to not allow to
> >>publish
> >> >> those for user testing. We (the foundation) already do this via our
> >> >> snapshots maven repos...
> >> >>
> >> >> And there are also different layers of 'legal'. There is no law in
> >>the US
> >> >> nor otherwhere in the world who requires a VOTE before an opensource
> >> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
> >> >>
> >> >> BUT: it is an ASF policy and thus binding for all our projects to
> >>VOTE on
> >> >> releases.
> >> >> And it is a really good one as it increases the technical and legal
> >> >> quality of our products! It's really a good thing to have 10+ people
> >>looking
> >> >> at a release and e.g. discovering that a file has the wrong license
> >>and
> >> >> should get removed again for example. And of course it helps
> >>reducing the
> >> >> risk from getting sued because we obviously try to minimize human
> >>errors.
> >> >>
> >> >> @Shane I'm not sure how many ASF members are subscribed to the legal
> >>list,
> >> >> maybe it is enough if we just rise awareness.
> >> >>
> >> >> LieGrue,
> >> >> strub
> >> >>
> >> >>
> >> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> "But the point already got covered and answered dozens of times imo.
> >>The
> >> >> answer is that the ALv2 protects the foundation and also the release
> >>manager
> >> >> already for all bona fides cases. End of story."
> >> >>
> >> >>
> >> >> Interesting for myself to note that it was communicated very
> >>directly to
> >> >> Cordova that this *was not* the case. Votes are a necessary
> >>component for a
> >> >> valid (aka legal) release. Also interesting for me to discover in
> >>this
> >> >> thread that the release policy is not adhered to by all ASF
> >>projects. We
> >> >> were lead to believe the rules are immutable, all projects obey
> >>them. End of
> >> >> story.
> >> >>
> >> >> I am dismayed to discover this is not the case and Cordova was
> >>singled
> >> >> out.
> >> >>
> >> >> However, clarity here is a great starting to amending the rules, and
> >>I
> >> >> recognize this effort is not forum for that. My perspective: the
> >>vote is a
> >> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
> >>computer
> >> >> (aka CI system) and not a human and I am very happy to hear there is
> >> >> precedent for this with other projects.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> 
> 
> ---------------------------------------------------------------------
> 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

Re: Release Policy

[Mark Struberg <st...@yahoo.de>]

Brian, you mixed up quite a few things. 


I'll try to explain again:
> Ok, so end user software needs a vote to be a release and all projects 
are doing this without exception. If they are that is bad. Got it. 

Yes, all ASF projects need a VOTE on their official releases. The question is rather whether a nightly build or a published snapshot is a 'release' in this sense.

This is also something which Joe Bowser got wrong it seems.

There is a difference between "ASF Release" and 'release' in the sense of 'making something technically available on the internet'. There is a huge difference in the quality we guarantee. That's like having a publicly accessible water pipe which says "only for gardening, this water is not for drinking!" vs a "drinking water" shield on it. 


> "But the point already got covered and answered dozens of times imo. The answer 
is that the ALv2 

> protects the foundation and also the release manager 
already 

> for all bona fides cases. End of story."


It is correct from a LEGAL perspective but the factum that some code is really ALv2 might be in question .

I have to elaborate on this a bit.

Whether a certain piece of code you *originary* produced is [insertlicensehere] or not depends only on YOUR will. If you knowingly and willingly define it should be ALv2 then this is it. You don't even need to publish it. You don't even need to type it into a computer. Just writing it on a toilet paper would be enough *from a legal perspective*. So far so good. But this is not good enough from a FOUNDATION point of view!
How should other project members, e.g. the release manager know that you originally wrote the code yourself? What if someone checks in code which has a GPLv2 or other Category X [1] license? Legally a single release manager which is 100% sure that he knows all this would be enough. But who likes to be that guy who puts all the weight on his own shoulders? To not let such things slip through to an *official* ASF project release and to lay this weight on many shoulders we do the VOTE stuff. 10 pair of eyes just see much more than a single one.


summary: Amongst other things the VOTE is for checking whether the code REALLY is ALv2. Because only then the aforementioned legal statement comes into effect.

And once again, there is a difference between what law requires us to do (as a bare minimum) and the quality level aka release policy we gave ourselves (for good reasons). And to make it even more complicated: there re legal rules which are required to get fulfilled in some cases which are NOT covered by our release policy. E.g. the security export restriction paperwork for all parts which contain or use encryption of a certain kind...


LieGrue,
strub


PS: hope I do not confuse people even more
PPS: legal stuff is like permute - it always looks slightly different depending on the angle 



[1] http://www.apache.org/legal/3party.html



On Friday, 23 May 2014, 22:52, Brian LeRoux <b...@brian.io> wrote:
 

>
>
>Ok, so end user software needs a vote to be a release and all projects are doing this without exception. If they are that is bad. Got it. 
>
>Earlier: 
>
>"But the
 point already got covered and answered dozens of times imo. The answer 
is that the ALv2 protects the foundation and also the release manager 
already for all bona fides cases. End of story."
>
>Is the above statement incorrect also? 
>
>
>
>
>
>On Fri, May 23, 2014 at 3:19 PM, Mark Thomas <ma...@apache.org> wrote:
>
>On 23/05/2014 21:04, Joe Bowser wrote:
>>> On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti <pe...@apache.org> wrote:
>>>> On 23/05/2014 Brian LeRoux wrote:
>>>>>
>>>>> Furthermore some projects such as OpenOffice mentioned
>>>>> earlier do not follow the policy.
>>>>
>>>>
>>>> OpenOffice does follow the policy. The only "special" thing OpenOffice did
>>>> is to advertise development snapshots towards version 4.1 (these are NOT
>>>> releases! we conduct formal votes on ALL releases, including beta releases!)
>>>> outside the dev mailing list since we have a dedicated QA mailing lists and
>>>> a testers community that does not coincide with our developers. And this was
>>>> discussed in advance with both the board and the infrastructure lists.
>>>>
>>>
>>> So, a snapshot is not a release?
>>
>>A snapshot is a release if only if it has been voted on as such by the
>>PMC. It would also have to be tagged as part of the release which to my
>>mind means it isn't really a snapshot. However the label that is
>>attached to the release (RC, beta, stable, snapshot, etc.) is
>>irrelevant. What matters is did the PMC vote on it. It the PMC voted
>>(and assuming the rest of the release policy was followed) and the vote
>>passed, it is a release. If that didn't happen then it isn't a release.
>>
>>
>>
>>> The problem is that there is one rule
>>> for certain projects that have the board's favour and another for
>>> projects that the board chooses to pick on for unknown reasons.
>>
>>Please provide some evidence to back up that assertion. I have been
>>following a reasonable proportion if the discussion around Cordova and
>>releases and, while I have seen plenty of evidence that the Cordova
>>community doesn't like the constraints imposed by the ASF release
>>policy, I have seen no evidence of the board doing anything other than
>>requiring Cordova to follow the same release policy every other ASF
>>project is expected to follow.
>>
>>If you are aware of any other ASF project not following the ASF release
>>policy then please make the board aware. The board does not actively
>>monitor the day to day activities of every project. If there are
>>problems they rely on the VP to make them aware via the quarterly
>>reports and if that route fails they rely on others in and around the
>>project to bring the problem to their attention.
>>
>>
>>> Why isn't a snapshot build a release?
>>
>>Short answer - because the PMC didn't vote. Long answer - see above.
>>
>>In this particular case this was not an OpenOffice release because it
>>was not advertised to the end-user community for that software. It is
>>perfectly within the intent of the current policy to include members of
>>dedicated QA and test lists in the same category as members of the dev
>>list. It is to the credit of the OpenOffice community that they went as
>>far as checking that their understanding of the policy was correct
>>before they did anything.
>>
>>What would not be acceptable would be for OpenOffice to start
>>advertising snapshots to their end-user community unless votes had taken
>>place and those snapshots had been formally released.
>>
>>Mark
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
>
>

Re: Release Policy

[Mark Struberg <st...@yahoo.de>]

> As a further food of thoughts: if some person adds the ALv2 header to secret code of 

> his 
customer and publishes it on github, what would this mean? 
> And there is 
no RM involved yet... 


Just became aware that this might get misinterpreted again: Of course he will get sued because even if the code is labelled 'Alv2' doesn't mean it really is. So yes, he might get *successfully* sued. What I tried to say is that the legal aspect mainly depends on the content and not so much about who actually shipped it. The company will not sue github but the person who added the code. 

On Saturday, 24 May 2014, 8:53, Mark Struberg <st...@yahoo.de> wrote:
 

>
>
>Mark you mix up the legal aspect and the practical one.
>
>
>The legal side is that the ALv2 pretty much ensures that you as author and as RM are not to blame. 
>
>Or course this only is true for parts which we do _not_ injure the rules of the ALv2.
>
>
>Think about it: 
>* how many Linux repos take
 our exact sources and binaries without adding patches etc? I'm not aware of any. They all do their own 'release'
>* how many $BIGCO JavaEE vendors take some apache sources (even 'random' snapshots^^) modify them and 'release' em on their own?
>* how many projects are around on github, sourceforge etc which are not getting sued?
>
>As a further food of thoughts: if some person adds the ALv2 header to secret code of his customer and publishes it on github, what would this mean? And there is no RM involved yet... 
>
>
>
>The practical side is that due to the voting process we say "all the stuff in our SVN which is not voted on yet is not yet checked and did not pass our marks". And with the VOTE (beside _trying_ to ensure the quality) we spread the risk from a single RM to many people plus the foundation. And this reduces the risk _in practice_! So it IS important.
>
>
>
>Because the truth is: any person or company can sue anyone at anytime. It's really only a matter of how big the chances are that he succeeds and how big the costs are in comparison to the expected benefit. And it's also of course a matter of the public perception. If $BIGCO sues a single person then there will only be a few who take notice. If $BIGCO sues the ASF, then there would be pretty huge rumble. So yes, from a practical aspect it really matters.
>
>
>Regarding the bona fides vs mala fides example I brought and seemed to have confused people. 
>
>What I meant is: if some person knowingly adds a backdoor then he might (and hopefully will) get sued. And in this case neither the ALv2 nor the ASF can and will help.
>And the opposite is also true. A RM acting in good faith and carefully doing his job has not that much to fear.
>
>Also the spectrum of suites which might follow is pretty broad. This might range from criminal prosecution (backdoor case) over civil compensation (money) to just having us to remove the code in question ('Unterlassungsklage', the most likely case).
>
>I wont go into further details because we are really far away from the original topic of this thread.
>For interested people I suggest to start a law study - it's really fun and interesting most of the
 time...
>
>LieGrue,
>strub
>
>
>
>
>On Friday, 23 May 2014, 23:49, Mark Thomas <ma...@apache.org> wrote:
> 
>
>>
>>
>>On 23/05/2014 21:51, Brian LeRoux wrote:
>>
>><snip/>
>>
>>> Earlier:
>>> 
>>> "But the point already got covered and answered dozens of times imo. The
>>> answer is that the ALv2 protects the foundation and also the release
>>> manager already for all bona fides
 cases. End of story."
>>
>>I have not seen that statement expressed in any previous discussion I
>>can recall about the release policy by a board member, V.P. Legal or one
>>of our lawyers.
>>
>>It also appears to me (as a non-lawyer) to be obviously false.
>>
>>If $BigCo decides tomorrow that some Tomcat feature infringes one or
>>more patents that $BigCo owns and therefore $BigCo decides to sue me as
>>the release manager then I don't see anything in the ALv2 that helps me.
>>
>>However, I do so the release policy allowing me to say "Hang on. I
>>didn't release that, the ASF did. Take this up with them." as well as
>>the ASF saying "You did everything you were meant to. We'll do
>>everything we can to redirect this hassle from you to us."
>>
>>Now there is the question of whether the court in question would allow
>>the ASF to step in in my place (I'm sure there is a legal term for that
>>but I forget what it is) but I do recall discussions that concluded that
>>the release policy makes it much, much more likely that the court would
>>allow that.
>>
>>> Is the above statement incorrect also?
>>
>>It appears so to me.
>>
>>Mark
>>
>>
>>> 
>>> 
>>> 
>>> On Fri, May 23, 2014 at 3:19 PM, Mark Thomas <markt@apache.org
>>> <ma...@apache.org>> wrote:
>>> 
>>>     On 23/05/2014 21:04, Joe Bowser wrote:
>>>     > On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti
>>>     <pescetti@apache.org <ma...@apache.org>> wrote:
>>>     >> On 23/05/2014 Brian LeRoux wrote:
>>>     >>>
>>>     >>> Furthermore some projects such as OpenOffice mentioned
>>>     >>> earlier do not follow the policy.
>>>    
 >>
>>>     >>
>>> 
    >> OpenOffice does follow the policy. The only "special" thing
>>>     OpenOffice did
>>>     >> is to advertise development snapshots towards version 4.1 (these
>>>     are NOT
>>>     >> releases! we conduct formal votes on ALL releases, including beta
>>>     releases!)
>>>     >> outside the dev mailing list since we have a dedicated QA mailing
>>>     lists and
>>>     >> a testers community that does not coincide with our developers.
>>>     And this was
>>>     >> discussed in advance with both the board and the infrastructure
>>>     lists.
>>>     >>
>>> 
    >
>>>     > So, a snapshot is not a release?
>>> 
>>>     A snapshot is a release if only if it has been voted on as such by the
>>>     PMC. It would also have to be tagged as part of the release which to my
>>>     mind means it isn't really a snapshot. However the label that is
>>>     attached to the release (RC, beta, stable, snapshot, etc.) is
>>>     irrelevant. What matters is did the PMC vote on it. It the PMC voted
>>>     (and assuming the rest of the release policy was followed) and the vote
>>>     passed, it is a release. If that didn't happen then it isn't a release.
>>> 
>>> 
>>>     > The problem is that there is one rule
>>>     > for certain projects that have the board's favour and another for
>>>     > projects that the board chooses to pick on for unknown reasons.
>>> 
>>>     Please provide some evidence to back up that assertion. I have been
>>>     following a reasonable proportion if the discussion around Cordova and
>>>     releases and, while I have seen plenty of evidence that the Cordova
>>>     community doesn't like the constraints imposed by the ASF release
>>>     policy, I have seen no evidence of the board doing anything other than
>>>     requiring Cordova to follow the same release policy every other ASF
>>>     project is expected to follow.
>>> 
>>> 
    If you are aware of any other ASF project not following the ASF release
>>>     policy then please make the board aware. The board does not actively
>>>     monitor the day to day activities of every project. If there are
>>>     problems they rely on the VP to make them aware via the quarterly
>>>     reports and if that route fails they rely on others in and around the
>>>     project to bring the problem to their attention.
>>> 
>>>     > Why isn't a snapshot build a release?
>>> 
>>>     Short answer - because the PMC didn't vote. Long answer - see above.
>>> 
>>>     In this particular case this was not an OpenOffice release because it
>>>     was
 not advertised to the end-user community for that software. It is
>>>     perfectly within the intent of the current policy to include members of
>>>     dedicated QA and test lists in the same category as members of the dev
>>>     list. It is to the credit of the OpenOffice community that they went as
>>>     far as checking that their understanding of the policy was correct
>>>     before they did anything.
>>> 
>>>     What would not be acceptable would be for OpenOffice to start
>>>     advertising snapshots to their end-user community unless votes had taken
>>>     place and those snapshots had been formally released.
>>> 
>>>     Mark
>>> 
>>> 
>>>     ---------------------------------------------------------------------
>>>     To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>>     <ma...@apache.org>
>>>     For additional commands, e-mail: legal-discuss-help@apache.org
>>>     <ma...@apache.org>
>>
>>> 
>>> 
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>>
>>
>
>

Re: Release Policy

[Mark Struberg <st...@yahoo.de>]

Mark you mix up the legal aspect and the practical one.

The legal side is that the ALv2 pretty much ensures that you as author and as RM are not to blame. 

Or course this only is true for parts which we do _not_ injure the rules of the ALv2.


Think about it: 
* how many Linux repos take our exact sources and binaries without adding patches etc? I'm not aware of any. They all do their own 'release'
* how many $BIGCO JavaEE vendors take some apache sources (even 'random' snapshots^^) modify them and 'release' em on their own?
* how many projects are around on github, sourceforge etc which are not getting sued?

As a further food of thoughts: if some person adds the ALv2 header to secret code of his customer and publishes it on github, what would this mean? And there is no RM involved yet... 



The practical side is that due to the voting process we say "all the stuff in our SVN which is not voted on yet is not yet checked and did not pass our marks". And with the VOTE (beside _trying_ to ensure the quality) we spread the risk from a single RM to many people plus the foundation. And this reduces the risk _in practice_! So it IS important.


Because the truth is: any person or company can sue anyone at anytime. It's really only a matter of how big the chances are that he succeeds and how big the costs are in comparison to the expected benefit. And it's also of course a matter of the public perception. If $BIGCO sues a single person then there will only be a few who take notice. If $BIGCO sues the ASF, then there would be pretty huge rumble. So yes, from a practical aspect it really matters.

Regarding the bona fides vs mala fides example I brought and seemed to have confused people. 

What I meant is: if some person knowingly adds a backdoor then he might (and hopefully will) get sued. And in this case neither the ALv2 nor the ASF can and will help.
And the opposite is also true. A RM acting in good faith and carefully doing his job has not that much to fear.

Also the spectrum of suites which might follow is pretty broad. This might range from criminal prosecution (backdoor case) over civil compensation (money) to just having us to remove the code in question ('Unterlassungsklage', the most likely case).

I wont go into further details because we are really far away from the original topic of this thread.
For interested people I suggest to start a law study - it's really fun and interesting most of the time...

LieGrue,
strub



On Friday, 23 May 2014, 23:49, Mark Thomas <ma...@apache.org> wrote:
 

>
>
>On 23/05/2014 21:51, Brian LeRoux wrote:
>
><snip/>
>
>> Earlier:
>> 
>> "But the point already got covered and answered dozens of times imo. The
>> answer is that the ALv2 protects the foundation and also the release
>> manager already for all bona fides
 cases. End of story."
>
>I have not seen that statement expressed in any previous discussion I
>can recall about the release policy by a board member, V.P. Legal or one
>of our lawyers.
>
>It also appears to me (as a non-lawyer) to be obviously false.
>
>If $BigCo decides tomorrow that some Tomcat feature infringes one or
>more patents that $BigCo owns and therefore $BigCo decides to sue me as
>the release manager then I don't see anything in the ALv2 that helps me.
>
>However, I do so the release policy allowing me to say "Hang on. I
>didn't release that, the ASF did. Take this up with them." as well as
>the ASF saying "You did everything you were meant to. We'll do
>everything we can to redirect this hassle from you to us."
>
>Now there is the question of whether the court in question would allow
>the ASF to step in in my place (I'm sure there is a legal term for that
>but I forget what it is) but I do recall discussions that concluded that
>the release policy makes it much, much more likely that the court would
>allow that.
>
>> Is the above statement incorrect also?
>
>It appears so to me.
>
>Mark
>
>
>> 
>> 
>> 
>> On Fri, May 23, 2014 at 3:19 PM, Mark Thomas <markt@apache.org
>> <ma...@apache.org>> wrote:
>> 
>>     On 23/05/2014 21:04, Joe Bowser wrote:
>>     > On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti
>>     <pescetti@apache.org <ma...@apache.org>> wrote:
>>     >> On 23/05/2014 Brian LeRoux wrote:
>>     >>>
>>     >>> Furthermore some projects such as OpenOffice mentioned
>>     >>> earlier do not follow the policy.
>>     >>
>>     >>
>> 
    >> OpenOffice does follow the policy. The only "special" thing
>>     OpenOffice did
>>     >> is to advertise development snapshots towards version 4.1 (these
>>     are NOT
>>     >> releases! we conduct formal votes on ALL releases, including beta
>>     releases!)
>>     >> outside the dev mailing list since we have a dedicated QA mailing
>>     lists and
>>     >> a testers community that does not coincide with our developers.
>>     And this was
>>     >> discussed in advance with both the board and the infrastructure
>>     lists.
>>     >>
>> 
    >
>>     > So, a snapshot is not a release?
>> 
>>     A snapshot is a release if only if it has been voted on as such by the
>>     PMC. It would also have to be tagged as part of the release which to my
>>     mind means it isn't really a snapshot. However the label that is
>>     attached to the release (RC, beta, stable, snapshot, etc.) is
>>     irrelevant. What matters is did the PMC vote on it. It the PMC voted
>>     (and assuming the rest of the release policy was followed) and the vote
>>     passed, it is a release. If that didn't happen then it isn't a release.
>> 
>> 
>>     > The problem is that there is one rule
>>     > for certain projects that have the board's favour and another for
>>     > projects that the board chooses to pick on for unknown reasons.
>> 
>>     Please provide some evidence to back up that assertion. I have been
>>     following a reasonable proportion if the discussion around Cordova and
>>     releases and, while I have seen plenty of evidence that the Cordova
>>     community doesn't like the constraints imposed by the ASF release
>>     policy, I have seen no evidence of the board doing anything other than
>>     requiring Cordova to follow the same release policy every other ASF
>>     project is expected to follow.
>> 
>> 
    If you are aware of any other ASF project not following the ASF release
>>     policy then please make the board aware. The board does not actively
>>     monitor the day to day activities of every project. If there are
>>     problems they rely on the VP to make them aware via the quarterly
>>     reports and if that route fails they rely on others in and around the
>>     project to bring the problem to their attention.
>> 
>>     > Why isn't a snapshot build a release?
>> 
>>     Short answer - because the PMC didn't vote. Long answer - see above.
>> 
>>     In this particular case this was not an OpenOffice release because it
>>     was
 not advertised to the end-user community for that software. It is
>>     perfectly within the intent of the current policy to include members of
>>     dedicated QA and test lists in the same category as members of the dev
>>     list. It is to the credit of the OpenOffice community that they went as
>>     far as checking that their understanding of the policy was correct
>>     before they did anything.
>> 
>>     What would not be acceptable would be for OpenOffice to start
>>     advertising snapshots to their end-user community unless votes had taken
>>     place and those snapshots had been formally released.
>> 
>>     Mark
>> 
>> 
>>     ---------------------------------------------------------------------
>>     To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>     <ma...@apache.org>
>>     For additional commands, e-mail: legal-discuss-help@apache.org
>>     <ma...@apache.org>
>
>> 
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>For additional commands, e-mail: legal-discuss-help@apache.org
>
>
>
>

Re: Release Policy

[Mark Thomas <ma...@apache.org>]

On 23/05/2014 21:51, Brian LeRoux wrote:

<snip/>

> Earlier:
> 
> "But the point already got covered and answered dozens of times imo. The
> answer is that the ALv2 protects the foundation and also the release
> manager already for all bona fides cases. End of story."

I have not seen that statement expressed in any previous discussion I
can recall about the release policy by a board member, V.P. Legal or one
of our lawyers.

It also appears to me (as a non-lawyer) to be obviously false.

If $BigCo decides tomorrow that some Tomcat feature infringes one or
more patents that $BigCo owns and therefore $BigCo decides to sue me as
the release manager then I don't see anything in the ALv2 that helps me.

However, I do so the release policy allowing me to say "Hang on. I
didn't release that, the ASF did. Take this up with them." as well as
the ASF saying "You did everything you were meant to. We'll do
everything we can to redirect this hassle from you to us."

Now there is the question of whether the court in question would allow
the ASF to step in in my place (I'm sure there is a legal term for that
but I forget what it is) but I do recall discussions that concluded that
the release policy makes it much, much more likely that the court would
allow that.

> Is the above statement incorrect also?

It appears so to me.

Mark


> 
> 
> 
> On Fri, May 23, 2014 at 3:19 PM, Mark Thomas <markt@apache.org
> <ma...@apache.org>> wrote:
> 
>     On 23/05/2014 21:04, Joe Bowser wrote:
>     > On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti
>     <pescetti@apache.org <ma...@apache.org>> wrote:
>     >> On 23/05/2014 Brian LeRoux wrote:
>     >>>
>     >>> Furthermore some projects such as OpenOffice mentioned
>     >>> earlier do not follow the policy.
>     >>
>     >>
>     >> OpenOffice does follow the policy. The only "special" thing
>     OpenOffice did
>     >> is to advertise development snapshots towards version 4.1 (these
>     are NOT
>     >> releases! we conduct formal votes on ALL releases, including beta
>     releases!)
>     >> outside the dev mailing list since we have a dedicated QA mailing
>     lists and
>     >> a testers community that does not coincide with our developers.
>     And this was
>     >> discussed in advance with both the board and the infrastructure
>     lists.
>     >>
>     >
>     > So, a snapshot is not a release?
> 
>     A snapshot is a release if only if it has been voted on as such by the
>     PMC. It would also have to be tagged as part of the release which to my
>     mind means it isn't really a snapshot. However the label that is
>     attached to the release (RC, beta, stable, snapshot, etc.) is
>     irrelevant. What matters is did the PMC vote on it. It the PMC voted
>     (and assuming the rest of the release policy was followed) and the vote
>     passed, it is a release. If that didn't happen then it isn't a release.
> 
> 
>     > The problem is that there is one rule
>     > for certain projects that have the board's favour and another for
>     > projects that the board chooses to pick on for unknown reasons.
> 
>     Please provide some evidence to back up that assertion. I have been
>     following a reasonable proportion if the discussion around Cordova and
>     releases and, while I have seen plenty of evidence that the Cordova
>     community doesn't like the constraints imposed by the ASF release
>     policy, I have seen no evidence of the board doing anything other than
>     requiring Cordova to follow the same release policy every other ASF
>     project is expected to follow.
> 
>     If you are aware of any other ASF project not following the ASF release
>     policy then please make the board aware. The board does not actively
>     monitor the day to day activities of every project. If there are
>     problems they rely on the VP to make them aware via the quarterly
>     reports and if that route fails they rely on others in and around the
>     project to bring the problem to their attention.
> 
>     > Why isn't a snapshot build a release?
> 
>     Short answer - because the PMC didn't vote. Long answer - see above.
> 
>     In this particular case this was not an OpenOffice release because it
>     was not advertised to the end-user community for that software. It is
>     perfectly within the intent of the current policy to include members of
>     dedicated QA and test lists in the same category as members of the dev
>     list. It is to the credit of the OpenOffice community that they went as
>     far as checking that their understanding of the policy was correct
>     before they did anything.
> 
>     What would not be acceptable would be for OpenOffice to start
>     advertising snapshots to their end-user community unless votes had taken
>     place and those snapshots had been formally released.
> 
>     Mark
> 
> 
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>     <ma...@apache.org>
>     For additional commands, e-mail: legal-discuss-help@apache.org
>     <ma...@apache.org>
> 
> 


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

Re: Release Policy

[Davanum Srinivas <da...@gmail.com>]

Brian,

IANAL. I do not remember seeing it as a goal when ALv2 was drafted
("to protect the foundation argument") [1], i don't see any reference
to the foundation in the ALv2 text itself and i dont see it any of the
FAQ or web pages from the legal committee.

[1] http://apache.markmail.org/thread/p6xtxoqb5n4juhfd

On Fri, May 23, 2014 at 5:20 PM, Brian LeRoux <b...@brian.io> wrote:
> Actually, no that doesn't clear it up. To me that says, the PMC exists to
> thwart individual liability. Fair enough. A PMC initiated robot that presses
> a button to launch a release on ./dist should suffice then.
>
> The earlier statement made here:
>
>
> ""But the point already got covered and answered dozens of times imo. The
> answer is that the ALv2 protects the foundation and also the release manager
> already for all bona fides cases. End of story.""
>
> …seems to contradict that is even necessary.
>
> Sorry I'm not trying to be difficult (REALLY!) but this is very unclear, and
> obviously it is very crucially important to be clear. The purpose of the
> thread and initiative for clarity.
>
>
>
> On Fri, May 23, 2014 at 4:14 PM, Davanum Srinivas <da...@gmail.com> wrote:
>>
>> Brian,
>>
>> This really old email from Roy may help -
>> http://markmail.org/message/ofxh3lkygcxiigf3
>>
>> -- dims
>>
>> On Fri, May 23, 2014 at 4:51 PM, Brian LeRoux <b...@brian.io> wrote:
>> > Ok, so end user software needs a vote to be a release and all projects
>> > are
>> > doing this without exception. If they are that is bad. Got it.
>> >
>> > Earlier:
>> >
>> > "But the point already got covered and answered dozens of times imo. The
>> > answer is that the ALv2 protects the foundation and also the release
>> > manager
>> > already for all bona fides cases. End of story."
>> >
>> > Is the above statement incorrect also?
>> >
>> >
>> >
>> > On Fri, May 23, 2014 at 3:19 PM, Mark Thomas <ma...@apache.org> wrote:
>> >>
>> >> On 23/05/2014 21:04, Joe Bowser wrote:
>> >> > On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti
>> >> > <pe...@apache.org>
>> >> > wrote:
>> >> >> On 23/05/2014 Brian LeRoux wrote:
>> >> >>>
>> >> >>> Furthermore some projects such as OpenOffice mentioned
>> >> >>> earlier do not follow the policy.
>> >> >>
>> >> >>
>> >> >> OpenOffice does follow the policy. The only "special" thing
>> >> >> OpenOffice
>> >> >> did
>> >> >> is to advertise development snapshots towards version 4.1 (these are
>> >> >> NOT
>> >> >> releases! we conduct formal votes on ALL releases, including beta
>> >> >> releases!)
>> >> >> outside the dev mailing list since we have a dedicated QA mailing
>> >> >> lists
>> >> >> and
>> >> >> a testers community that does not coincide with our developers. And
>> >> >> this was
>> >> >> discussed in advance with both the board and the infrastructure
>> >> >> lists.
>> >> >>
>> >> >
>> >> > So, a snapshot is not a release?
>> >>
>> >> A snapshot is a release if only if it has been voted on as such by the
>> >> PMC. It would also have to be tagged as part of the release which to my
>> >> mind means it isn't really a snapshot. However the label that is
>> >> attached to the release (RC, beta, stable, snapshot, etc.) is
>> >> irrelevant. What matters is did the PMC vote on it. It the PMC voted
>> >> (and assuming the rest of the release policy was followed) and the vote
>> >> passed, it is a release. If that didn't happen then it isn't a release.
>> >>
>> >>
>> >> > The problem is that there is one rule
>> >> > for certain projects that have the board's favour and another for
>> >> > projects that the board chooses to pick on for unknown reasons.
>> >>
>> >> Please provide some evidence to back up that assertion. I have been
>> >> following a reasonable proportion if the discussion around Cordova and
>> >> releases and, while I have seen plenty of evidence that the Cordova
>> >> community doesn't like the constraints imposed by the ASF release
>> >> policy, I have seen no evidence of the board doing anything other than
>> >> requiring Cordova to follow the same release policy every other ASF
>> >> project is expected to follow.
>> >>
>> >> If you are aware of any other ASF project not following the ASF release
>> >> policy then please make the board aware. The board does not actively
>> >> monitor the day to day activities of every project. If there are
>> >> problems they rely on the VP to make them aware via the quarterly
>> >> reports and if that route fails they rely on others in and around the
>> >> project to bring the problem to their attention.
>> >>
>> >> > Why isn't a snapshot build a release?
>> >>
>> >> Short answer - because the PMC didn't vote. Long answer - see above.
>> >>
>> >> In this particular case this was not an OpenOffice release because it
>> >> was not advertised to the end-user community for that software. It is
>> >> perfectly within the intent of the current policy to include members of
>> >> dedicated QA and test lists in the same category as members of the dev
>> >> list. It is to the credit of the OpenOffice community that they went as
>> >> far as checking that their understanding of the policy was correct
>> >> before they did anything.
>> >>
>> >> What would not be acceptable would be for OpenOffice to start
>> >> advertising snapshots to their end-user community unless votes had
>> >> taken
>> >> place and those snapshots had been formally released.
>> >>
>> >> Mark
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> For additional commands, e-mail: legal-discuss-help@apache.org
>> >>
>> >
>>
>>
>>
>> --
>> Davanum Srinivas :: http://davanum.wordpress.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>



-- 
Davanum Srinivas :: http://davanum.wordpress.com

On Fri, May 23, 2014 at 5:20 PM, Brian LeRoux <b...@brian.io> wrote:
> Actually, no that doesn't clear it up. To me that says, the PMC exists to
> thwart individual liability. Fair enough. A PMC initiated robot that presses
> a button to launch a release on ./dist should suffice then.
>
> The earlier statement made here:
>
> ""But the point already got covered and answered dozens of times imo. The
> answer is that the ALv2 protects the foundation and also the release manager
> already for all bona fides cases. End of story.""
>
> …seems to contradict that is even necessary.
>
> Sorry I'm not trying to be difficult (REALLY!) but this is very unclear, and
> obviously it is very crucially important to be clear. The purpose of the
> thread and initiative for clarity.
>
>
>
> On Fri, May 23, 2014 at 4:14 PM, Davanum Srinivas <da...@gmail.com> wrote:
>>
>> Brian,
>>
>> This really old email from Roy may help -
>> http://markmail.org/message/ofxh3lkygcxiigf3
>>
>> -- dims
>>
>> On Fri, May 23, 2014 at 4:51 PM, Brian LeRoux <b...@brian.io> wrote:
>> > Ok, so end user software needs a vote to be a release and all projects
>> > are
>> > doing this without exception. If they are that is bad. Got it.
>> >
>> > Earlier:
>> >
>> > "But the point already got covered and answered dozens of times imo. The
>> > answer is that the ALv2 protects the foundation and also the release
>> > manager
>> > already for all bona fides cases. End of story."
>> >
>> > Is the above statement incorrect also?
>> >
>> >
>> >
>> > On Fri, May 23, 2014 at 3:19 PM, Mark Thomas <ma...@apache.org> wrote:
>> >>
>> >> On 23/05/2014 21:04, Joe Bowser wrote:
>> >> > On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti
>> >> > <pe...@apache.org>
>> >> > wrote:
>> >> >> On 23/05/2014 Brian LeRoux wrote:
>> >> >>>
>> >> >>> Furthermore some projects such as OpenOffice mentioned
>> >> >>> earlier do not follow the policy.
>> >> >>
>> >> >>
>> >> >> OpenOffice does follow the policy. The only "special" thing
>> >> >> OpenOffice
>> >> >> did
>> >> >> is to advertise development snapshots towards version 4.1 (these are
>> >> >> NOT
>> >> >> releases! we conduct formal votes on ALL releases, including beta
>> >> >> releases!)
>> >> >> outside the dev mailing list since we have a dedicated QA mailing
>> >> >> lists
>> >> >> and
>> >> >> a testers community that does not coincide with our developers. And
>> >> >> this was
>> >> >> discussed in advance with both the board and the infrastructure
>> >> >> lists.
>> >> >>
>> >> >
>> >> > So, a snapshot is not a release?
>> >>
>> >> A snapshot is a release if only if it has been voted on as such by the
>> >> PMC. It would also have to be tagged as part of the release which to my
>> >> mind means it isn't really a snapshot. However the label that is
>> >> attached to the release (RC, beta, stable, snapshot, etc.) is
>> >> irrelevant. What matters is did the PMC vote on it. It the PMC voted
>> >> (and assuming the rest of the release policy was followed) and the vote
>> >> passed, it is a release. If that didn't happen then it isn't a release.
>> >>
>> >>
>> >> > The problem is that there is one rule
>> >> > for certain projects that have the board's favour and another for
>> >> > projects that the board chooses to pick on for unknown reasons.
>> >>
>> >> Please provide some evidence to back up that assertion. I have been
>> >> following a reasonable proportion if the discussion around Cordova and
>> >> releases and, while I have seen plenty of evidence that the Cordova
>> >> community doesn't like the constraints imposed by the ASF release
>> >> policy, I have seen no evidence of the board doing anything other than
>> >> requiring Cordova to follow the same release policy every other ASF
>> >> project is expected to follow.
>> >>
>> >> If you are aware of any other ASF project not following the ASF release
>> >> policy then please make the board aware. The board does not actively
>> >> monitor the day to day activities of every project. If there are
>> >> problems they rely on the VP to make them aware via the quarterly
>> >> reports and if that route fails they rely on others in and around the
>> >> project to bring the problem to their attention.
>> >>
>> >> > Why isn't a snapshot build a release?
>> >>
>> >> Short answer - because the PMC didn't vote. Long answer - see above.
>> >>
>> >> In this particular case this was not an OpenOffice release because it
>> >> was not advertised to the end-user community for that software. It is
>> >> perfectly within the intent of the current policy to include members of
>> >> dedicated QA and test lists in the same category as members of the dev
>> >> list. It is to the credit of the OpenOffice community that they went as
>> >> far as checking that their understanding of the policy was correct
>> >> before they did anything.
>> >>
>> >> What would not be acceptable would be for OpenOffice to start
>> >> advertising snapshots to their end-user community unless votes had
>> >> taken
>> >> place and those snapshots had been formally released.
>> >>
>> >> Mark
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> For additional commands, e-mail: legal-discuss-help@apache.org
>> >>
>> >
>>
>>
>>
>> --
>> Davanum Srinivas :: http://davanum.wordpress.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>



-- 
Davanum Srinivas :: http://davanum.wordpress.com

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

Re: Release Policy

[Brian LeRoux <b...@brian.io>]

Actually, no that doesn't clear it up. To me that says, the PMC exists to
thwart individual liability. Fair enough. A PMC initiated robot that
presses a button to launch a release on ./dist should suffice then.

The earlier statement made here:

""But the point already got covered and answered dozens of times imo. The
answer is that the ALv2 protects the foundation and also the release
manager already for all bona fides cases. End of story.""

…seems to contradict that is even necessary.

Sorry I'm not trying to be difficult (REALLY!) but this is very unclear,
and obviously it is very crucially important to be clear. The purpose of
the thread and initiative for clarity.



On Fri, May 23, 2014 at 4:14 PM, Davanum Srinivas <da...@gmail.com> wrote:

> Brian,
>
> This really old email from Roy may help -
> http://markmail.org/message/ofxh3lkygcxiigf3
>
> -- dims
>
> On Fri, May 23, 2014 at 4:51 PM, Brian LeRoux <b...@brian.io> wrote:
> > Ok, so end user software needs a vote to be a release and all projects
> are
> > doing this without exception. If they are that is bad. Got it.
> >
> > Earlier:
> >
> > "But the point already got covered and answered dozens of times imo. The
> > answer is that the ALv2 protects the foundation and also the release
> manager
> > already for all bona fides cases. End of story."
> >
> > Is the above statement incorrect also?
> >
> >
> >
> > On Fri, May 23, 2014 at 3:19 PM, Mark Thomas <ma...@apache.org> wrote:
> >>
> >> On 23/05/2014 21:04, Joe Bowser wrote:
> >> > On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti <
> pescetti@apache.org>
> >> > wrote:
> >> >> On 23/05/2014 Brian LeRoux wrote:
> >> >>>
> >> >>> Furthermore some projects such as OpenOffice mentioned
> >> >>> earlier do not follow the policy.
> >> >>
> >> >>
> >> >> OpenOffice does follow the policy. The only "special" thing
> OpenOffice
> >> >> did
> >> >> is to advertise development snapshots towards version 4.1 (these are
> >> >> NOT
> >> >> releases! we conduct formal votes on ALL releases, including beta
> >> >> releases!)
> >> >> outside the dev mailing list since we have a dedicated QA mailing
> lists
> >> >> and
> >> >> a testers community that does not coincide with our developers. And
> >> >> this was
> >> >> discussed in advance with both the board and the infrastructure
> lists.
> >> >>
> >> >
> >> > So, a snapshot is not a release?
> >>
> >> A snapshot is a release if only if it has been voted on as such by the
> >> PMC. It would also have to be tagged as part of the release which to my
> >> mind means it isn't really a snapshot. However the label that is
> >> attached to the release (RC, beta, stable, snapshot, etc.) is
> >> irrelevant. What matters is did the PMC vote on it. It the PMC voted
> >> (and assuming the rest of the release policy was followed) and the vote
> >> passed, it is a release. If that didn't happen then it isn't a release.
> >>
> >>
> >> > The problem is that there is one rule
> >> > for certain projects that have the board's favour and another for
> >> > projects that the board chooses to pick on for unknown reasons.
> >>
> >> Please provide some evidence to back up that assertion. I have been
> >> following a reasonable proportion if the discussion around Cordova and
> >> releases and, while I have seen plenty of evidence that the Cordova
> >> community doesn't like the constraints imposed by the ASF release
> >> policy, I have seen no evidence of the board doing anything other than
> >> requiring Cordova to follow the same release policy every other ASF
> >> project is expected to follow.
> >>
> >> If you are aware of any other ASF project not following the ASF release
> >> policy then please make the board aware. The board does not actively
> >> monitor the day to day activities of every project. If there are
> >> problems they rely on the VP to make them aware via the quarterly
> >> reports and if that route fails they rely on others in and around the
> >> project to bring the problem to their attention.
> >>
> >> > Why isn't a snapshot build a release?
> >>
> >> Short answer - because the PMC didn't vote. Long answer - see above.
> >>
> >> In this particular case this was not an OpenOffice release because it
> >> was not advertised to the end-user community for that software. It is
> >> perfectly within the intent of the current policy to include members of
> >> dedicated QA and test lists in the same category as members of the dev
> >> list. It is to the credit of the OpenOffice community that they went as
> >> far as checking that their understanding of the policy was correct
> >> before they did anything.
> >>
> >> What would not be acceptable would be for OpenOffice to start
> >> advertising snapshots to their end-user community unless votes had taken
> >> place and those snapshots had been formally released.
> >>
> >> Mark
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> For additional commands, e-mail: legal-discuss-help@apache.org
> >>
> >
>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

Re: Release Policy

[Davanum Srinivas <da...@gmail.com>]

Brian,

This really old email from Roy may help -
http://markmail.org/message/ofxh3lkygcxiigf3

-- dims

On Fri, May 23, 2014 at 4:51 PM, Brian LeRoux <b...@brian.io> wrote:
> Ok, so end user software needs a vote to be a release and all projects are
> doing this without exception. If they are that is bad. Got it.
>
> Earlier:
>
> "But the point already got covered and answered dozens of times imo. The
> answer is that the ALv2 protects the foundation and also the release manager
> already for all bona fides cases. End of story."
>
> Is the above statement incorrect also?
>
>
>
> On Fri, May 23, 2014 at 3:19 PM, Mark Thomas <ma...@apache.org> wrote:
>>
>> On 23/05/2014 21:04, Joe Bowser wrote:
>> > On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti <pe...@apache.org>
>> > wrote:
>> >> On 23/05/2014 Brian LeRoux wrote:
>> >>>
>> >>> Furthermore some projects such as OpenOffice mentioned
>> >>> earlier do not follow the policy.
>> >>
>> >>
>> >> OpenOffice does follow the policy. The only "special" thing OpenOffice
>> >> did
>> >> is to advertise development snapshots towards version 4.1 (these are
>> >> NOT
>> >> releases! we conduct formal votes on ALL releases, including beta
>> >> releases!)
>> >> outside the dev mailing list since we have a dedicated QA mailing lists
>> >> and
>> >> a testers community that does not coincide with our developers. And
>> >> this was
>> >> discussed in advance with both the board and the infrastructure lists.
>> >>
>> >
>> > So, a snapshot is not a release?
>>
>> A snapshot is a release if only if it has been voted on as such by the
>> PMC. It would also have to be tagged as part of the release which to my
>> mind means it isn't really a snapshot. However the label that is
>> attached to the release (RC, beta, stable, snapshot, etc.) is
>> irrelevant. What matters is did the PMC vote on it. It the PMC voted
>> (and assuming the rest of the release policy was followed) and the vote
>> passed, it is a release. If that didn't happen then it isn't a release.
>>
>>
>> > The problem is that there is one rule
>> > for certain projects that have the board's favour and another for
>> > projects that the board chooses to pick on for unknown reasons.
>>
>> Please provide some evidence to back up that assertion. I have been
>> following a reasonable proportion if the discussion around Cordova and
>> releases and, while I have seen plenty of evidence that the Cordova
>> community doesn't like the constraints imposed by the ASF release
>> policy, I have seen no evidence of the board doing anything other than
>> requiring Cordova to follow the same release policy every other ASF
>> project is expected to follow.
>>
>> If you are aware of any other ASF project not following the ASF release
>> policy then please make the board aware. The board does not actively
>> monitor the day to day activities of every project. If there are
>> problems they rely on the VP to make them aware via the quarterly
>> reports and if that route fails they rely on others in and around the
>> project to bring the problem to their attention.
>>
>> > Why isn't a snapshot build a release?
>>
>> Short answer - because the PMC didn't vote. Long answer - see above.
>>
>> In this particular case this was not an OpenOffice release because it
>> was not advertised to the end-user community for that software. It is
>> perfectly within the intent of the current policy to include members of
>> dedicated QA and test lists in the same category as members of the dev
>> list. It is to the credit of the OpenOffice community that they went as
>> far as checking that their understanding of the policy was correct
>> before they did anything.
>>
>> What would not be acceptable would be for OpenOffice to start
>> advertising snapshots to their end-user community unless votes had taken
>> place and those snapshots had been formally released.
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>



-- 
Davanum Srinivas :: http://davanum.wordpress.com

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

RE: Release Policy

[Lawrence Rosen <lr...@rosenlaw.com>]

'Twas written on this list:

> "But the point already got covered and answered dozens of times imo. The
answer is that the ALv2 protects the foundation and also the release manager
already for all bona fides cases. End of story."

Is the above statement incorrect also? 

The above statement is only part of the story. ASF has a fully-functioning
board of directors and complies (AFAIK) with all relevant laws. ASF obtains
D&O insurance to protect itself and its directors and officers from many
kinds of liability for negligence and to provide legal representation if
necessary. That is enough to encourage us to proceed with our activities
without worrying about random lawsuits.

 

"Bona fide cases" is not useful terminology in this context. I can assure
you that there are things that individuals could do here that would get them
in trouble. :-) If there is something specific you are worried about, speak
up.

 

/Larry

 

Lawrence Rosen

Rosenlaw & Einschlag ( <http://www.rosenlaw.com/> www.rosenlaw.com) 

3001 King Ranch Road, Ukiah, CA 95482

Cell: 707-478-8932   Fax: 707-485-1243

 

From: Dave Fisher [mailto:dave2wave@comcast.net] 
Sent: Saturday, May 24, 2014 10:41 AM
To: legal-discuss@apache.org
Subject: Re: Release Policy

 

 

On May 23, 2014, at 1:51 PM, Brian LeRoux wrote:





Ok, so end user software needs a vote to be a release and all projects are
doing this without exception. If they are that is bad. Got it. 

Earlier: 

"But the point already got covered and answered dozens of times imo. The
answer is that the ALv2 protects the foundation and also the release manager
already for all bona fides cases. End of story."

Is the above statement incorrect also? 

 

On Fri, May 23, 2014 at 3:19 PM, Mark Thomas <markt@apache.org
<ma...@apache.org> > wrote:



On 23/05/2014 21:04, Joe Bowser wrote:
> On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti <pescetti@apache.org
<ma...@apache.org> > wrote:
>> On 23/05/2014 Brian LeRoux wrote:
>>>
>>> Furthermore some projects such as OpenOffice mentioned
>>> earlier do not follow the policy.
>>
>>
>> OpenOffice does follow the policy. The only "special" thing OpenOffice
did
>> is to advertise development snapshots towards version 4.1 (these are NOT
>> releases! we conduct formal votes on ALL releases, including beta
releases!)
>> outside the dev mailing list since we have a dedicated QA mailing lists
and
>> a testers community that does not coincide with our developers. And this
was
>> discussed in advance with both the board and the infrastructure lists.
>>
>
> So, a snapshot is not a release?

A snapshot is a release if only if it has been voted on as such by the
PMC. It would also have to be tagged as part of the release which to my
mind means it isn't really a snapshot. However the label that is
attached to the release (RC, beta, stable, snapshot, etc.) is
irrelevant. What matters is did the PMC vote on it. It the PMC voted
(and assuming the rest of the release policy was followed) and the vote
passed, it is a release. If that didn't happen then it isn't a release.



> The problem is that there is one rule
> for certain projects that have the board's favour and another for
> projects that the board chooses to pick on for unknown reasons.

Please provide some evidence to back up that assertion. I have been
following a reasonable proportion if the discussion around Cordova and
releases and, while I have seen plenty of evidence that the Cordova
community doesn't like the constraints imposed by the ASF release
policy, I have seen no evidence of the board doing anything other than
requiring Cordova to follow the same release policy every other ASF
project is expected to follow.

If you are aware of any other ASF project not following the ASF release
policy then please make the board aware. The board does not actively
monitor the day to day activities of every project. If there are
problems they rely on the VP to make them aware via the quarterly
reports and if that route fails they rely on others in and around the
project to bring the problem to their attention.


> Why isn't a snapshot build a release?

Short answer - because the PMC didn't vote. Long answer - see above.

In this particular case this was not an OpenOffice release because it
was not advertised to the end-user community for that software. It is
perfectly within the intent of the current policy to include members of
dedicated QA and test lists in the same category as members of the dev
list. It is to the credit of the OpenOffice community that they went as
far as checking that their understanding of the policy was correct
before they did anything.

 

The snapshots are very carefully fenced as a developer / qa resource in
order to assure that when a release was made it would be of the highest
quality.

 

The PMC waited for complete consensus on the process and that took time - a
number of weeks.

 

Andrea did a very careful job communicating well within the ASF.






What would not be acceptable would be for OpenOffice to start
advertising snapshots to their end-user community unless votes had taken
place and those snapshots had been formally released.

 

Exactly.

 

Regards,

Dave






Mark



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

 

 

Re: Release Policy

[Dave Fisher <da...@comcast.net>]

On May 23, 2014, at 1:51 PM, Brian LeRoux wrote:

> Ok, so end user software needs a vote to be a release and all projects are doing this without exception. If they are that is bad. Got it. 
> 
> Earlier: 
> 
> "But the point already got covered and answered dozens of times imo. The answer is that the ALv2 protects the foundation and also the release manager already for all bona fides cases. End of story."
> 
> Is the above statement incorrect also? 
> 
> 
> 
> On Fri, May 23, 2014 at 3:19 PM, Mark Thomas <ma...@apache.org> wrote:
> On 23/05/2014 21:04, Joe Bowser wrote:
> > On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti <pe...@apache.org> wrote:
> >> On 23/05/2014 Brian LeRoux wrote:
> >>>
> >>> Furthermore some projects such as OpenOffice mentioned
> >>> earlier do not follow the policy.
> >>
> >>
> >> OpenOffice does follow the policy. The only "special" thing OpenOffice did
> >> is to advertise development snapshots towards version 4.1 (these are NOT
> >> releases! we conduct formal votes on ALL releases, including beta releases!)
> >> outside the dev mailing list since we have a dedicated QA mailing lists and
> >> a testers community that does not coincide with our developers. And this was
> >> discussed in advance with both the board and the infrastructure lists.
> >>
> >
> > So, a snapshot is not a release?
> 
> A snapshot is a release if only if it has been voted on as such by the
> PMC. It would also have to be tagged as part of the release which to my
> mind means it isn't really a snapshot. However the label that is
> attached to the release (RC, beta, stable, snapshot, etc.) is
> irrelevant. What matters is did the PMC vote on it. It the PMC voted
> (and assuming the rest of the release policy was followed) and the vote
> passed, it is a release. If that didn't happen then it isn't a release.
> 
> 
> > The problem is that there is one rule
> > for certain projects that have the board's favour and another for
> > projects that the board chooses to pick on for unknown reasons.
> 
> Please provide some evidence to back up that assertion. I have been
> following a reasonable proportion if the discussion around Cordova and
> releases and, while I have seen plenty of evidence that the Cordova
> community doesn't like the constraints imposed by the ASF release
> policy, I have seen no evidence of the board doing anything other than
> requiring Cordova to follow the same release policy every other ASF
> project is expected to follow.
> 
> If you are aware of any other ASF project not following the ASF release
> policy then please make the board aware. The board does not actively
> monitor the day to day activities of every project. If there are
> problems they rely on the VP to make them aware via the quarterly
> reports and if that route fails they rely on others in and around the
> project to bring the problem to their attention.
> 
> > Why isn't a snapshot build a release?
> 
> Short answer - because the PMC didn't vote. Long answer - see above.
> 
> In this particular case this was not an OpenOffice release because it
> was not advertised to the end-user community for that software. It is
> perfectly within the intent of the current policy to include members of
> dedicated QA and test lists in the same category as members of the dev
> list. It is to the credit of the OpenOffice community that they went as
> far as checking that their understanding of the policy was correct
> before they did anything.

The snapshots are very carefully fenced as a developer / qa resource in order to assure that when a release was made it would be of the highest quality.

The PMC waited for complete consensus on the process and that took time - a number of weeks.

Andrea did a very careful job communicating well within the ASF.

> 
> What would not be acceptable would be for OpenOffice to start
> advertising snapshots to their end-user community unless votes had taken
> place and those snapshots had been formally released.

Exactly.

Regards,
Dave

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

Re: Release Policy

[Brian LeRoux <b...@brian.io>]

Ok, so end user software needs a vote to be a release and all projects are
doing this without exception. If they are that is bad. Got it.

Earlier:

"But the point already got covered and answered dozens of times imo. The
answer is that the ALv2 protects the foundation and also the release
manager already for all bona fides cases. End of story."

Is the above statement incorrect also?



On Fri, May 23, 2014 at 3:19 PM, Mark Thomas <ma...@apache.org> wrote:

> On 23/05/2014 21:04, Joe Bowser wrote:
> > On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti <pe...@apache.org>
> wrote:
> >> On 23/05/2014 Brian LeRoux wrote:
> >>>
> >>> Furthermore some projects such as OpenOffice mentioned
> >>> earlier do not follow the policy.
> >>
> >>
> >> OpenOffice does follow the policy. The only "special" thing OpenOffice
> did
> >> is to advertise development snapshots towards version 4.1 (these are NOT
> >> releases! we conduct formal votes on ALL releases, including beta
> releases!)
> >> outside the dev mailing list since we have a dedicated QA mailing lists
> and
> >> a testers community that does not coincide with our developers. And
> this was
> >> discussed in advance with both the board and the infrastructure lists.
> >>
> >
> > So, a snapshot is not a release?
>
> A snapshot is a release if only if it has been voted on as such by the
> PMC. It would also have to be tagged as part of the release which to my
> mind means it isn't really a snapshot. However the label that is
> attached to the release (RC, beta, stable, snapshot, etc.) is
> irrelevant. What matters is did the PMC vote on it. It the PMC voted
> (and assuming the rest of the release policy was followed) and the vote
> passed, it is a release. If that didn't happen then it isn't a release.
>
>
> > The problem is that there is one rule
> > for certain projects that have the board's favour and another for
> > projects that the board chooses to pick on for unknown reasons.
>
> Please provide some evidence to back up that assertion. I have been
> following a reasonable proportion if the discussion around Cordova and
> releases and, while I have seen plenty of evidence that the Cordova
> community doesn't like the constraints imposed by the ASF release
> policy, I have seen no evidence of the board doing anything other than
> requiring Cordova to follow the same release policy every other ASF
> project is expected to follow.
>
> If you are aware of any other ASF project not following the ASF release
> policy then please make the board aware. The board does not actively
> monitor the day to day activities of every project. If there are
> problems they rely on the VP to make them aware via the quarterly
> reports and if that route fails they rely on others in and around the
> project to bring the problem to their attention.
>
> > Why isn't a snapshot build a release?
>
> Short answer - because the PMC didn't vote. Long answer - see above.
>
> In this particular case this was not an OpenOffice release because it
> was not advertised to the end-user community for that software. It is
> perfectly within the intent of the current policy to include members of
> dedicated QA and test lists in the same category as members of the dev
> list. It is to the credit of the OpenOffice community that they went as
> far as checking that their understanding of the policy was correct
> before they did anything.
>
> What would not be acceptable would be for OpenOffice to start
> advertising snapshots to their end-user community unless votes had taken
> place and those snapshots had been formally released.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

Re: Release Policy

[Mark Thomas <ma...@apache.org>]

On 23/05/2014 21:04, Joe Bowser wrote:
> On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti <pe...@apache.org> wrote:
>> On 23/05/2014 Brian LeRoux wrote:
>>>
>>> Furthermore some projects such as OpenOffice mentioned
>>> earlier do not follow the policy.
>>
>>
>> OpenOffice does follow the policy. The only "special" thing OpenOffice did
>> is to advertise development snapshots towards version 4.1 (these are NOT
>> releases! we conduct formal votes on ALL releases, including beta releases!)
>> outside the dev mailing list since we have a dedicated QA mailing lists and
>> a testers community that does not coincide with our developers. And this was
>> discussed in advance with both the board and the infrastructure lists.
>>
> 
> So, a snapshot is not a release?

A snapshot is a release if only if it has been voted on as such by the
PMC. It would also have to be tagged as part of the release which to my
mind means it isn't really a snapshot. However the label that is
attached to the release (RC, beta, stable, snapshot, etc.) is
irrelevant. What matters is did the PMC vote on it. It the PMC voted
(and assuming the rest of the release policy was followed) and the vote
passed, it is a release. If that didn't happen then it isn't a release.


> The problem is that there is one rule
> for certain projects that have the board's favour and another for
> projects that the board chooses to pick on for unknown reasons.

Please provide some evidence to back up that assertion. I have been
following a reasonable proportion if the discussion around Cordova and
releases and, while I have seen plenty of evidence that the Cordova
community doesn't like the constraints imposed by the ASF release
policy, I have seen no evidence of the board doing anything other than
requiring Cordova to follow the same release policy every other ASF
project is expected to follow.

If you are aware of any other ASF project not following the ASF release
policy then please make the board aware. The board does not actively
monitor the day to day activities of every project. If there are
problems they rely on the VP to make them aware via the quarterly
reports and if that route fails they rely on others in and around the
project to bring the problem to their attention.

> Why isn't a snapshot build a release?

Short answer - because the PMC didn't vote. Long answer - see above.

In this particular case this was not an OpenOffice release because it
was not advertised to the end-user community for that software. It is
perfectly within the intent of the current policy to include members of
dedicated QA and test lists in the same category as members of the dev
list. It is to the credit of the OpenOffice community that they went as
far as checking that their understanding of the policy was correct
before they did anything.

What would not be acceptable would be for OpenOffice to start
advertising snapshots to their end-user community unless votes had taken
place and those snapshots had been formally released.

Mark


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

Re: Release Policy

[Joe Bowser <bo...@gmail.com>]

On Fri, May 23, 2014 at 12:46 PM, Andrea Pescetti <pe...@apache.org> wrote:
> On 23/05/2014 Brian LeRoux wrote:
>>
>> Furthermore some projects such as OpenOffice mentioned
>> earlier do not follow the policy.
>
>
> OpenOffice does follow the policy. The only "special" thing OpenOffice did
> is to advertise development snapshots towards version 4.1 (these are NOT
> releases! we conduct formal votes on ALL releases, including beta releases!)
> outside the dev mailing list since we have a dedicated QA mailing lists and
> a testers community that does not coincide with our developers. And this was
> discussed in advance with both the board and the infrastructure lists.
>

So, a snapshot is not a release? The problem is that there is one rule
for certain projects that have the board's favour and another for
projects that the board chooses to pick on for unknown reasons.  Why
isn't a snapshot build a release?

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

Re: Release Policy

[Andrea Pescetti <pe...@apache.org>]

On 23/05/2014 Brian LeRoux wrote:
> Furthermore some projects such as OpenOffice mentioned
> earlier do not follow the policy.

OpenOffice does follow the policy. The only "special" thing OpenOffice 
did is to advertise development snapshots towards version 4.1 (these are 
NOT releases! we conduct formal votes on ALL releases, including beta 
releases!) outside the dev mailing list since we have a dedicated QA 
mailing lists and a testers community that does not coincide with our 
developers. And this was discussed in advance with both the board and 
the infrastructure lists.

So, if someone has understood that OpenOffice does not follow the 
release policy, it was my mistake since I wasn't clear. OpenOffice does 
follow the policy 100% and we even clarified doubts on the appropriate 
lists.

Regards,
   Andrea.

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

Re: Release Policy

[Brian LeRoux <b...@brian.io>]

Hey Mark, let's keep calm. Both of us are here to do right by our projects
and community. Right now my project has struggled to ship twice in 2014. In
2013 we shipped 67 times. We are hurting from this and that matters to me.
It should matter to you too b/c the ASF is not coming out better for it.

If a computer performed the actions a human did the same objectives could
be reached. Furthermore some projects such as OpenOffice mentioned earlier
do not follow the policy. Finally, it was also mentioned in this very
thread that there was no legal finality to it. (Search for "end of story".)
Was that incorrect?
On May 23, 2014 1:39 PM, "Mark Thomas" <ma...@apache.org> wrote:

> On 23/05/2014 19:33, Brian LeRoux wrote:
> > Yes it is as JJ says as long as a vote happens the tools matter not.
> > Though why the vote has to happen is yet to be clarified other than
> > meandering justifications.
>
> Brian,
>
> How may times and how many people have to repeat this before it sinks in?
>
> The PMC vote makes the release an act of the foundation rather than an
> act of the individual release manager. In the unlikely event of $BigCorp
> deciding to start a lawsuit over something in the release making the
> release an act of the foundation makes the foundation the target of any
> such lawsuit rather than the individual release manager.
>
> To put it another way, the vote protects the release manager from being
> the target of an expensive lawsuit. Yes the likelihood of this is low.
> However the potential impact should this happen is large. Therefore it
> is foundation policy that the vote takes place to ensure that release
> managers (whether they understand the protection they get from the
> process or not) are protected.
>
> Mark
>
>
> >
> > On May 23, 2014 11:56 AM, "Alex Harui" <aharui@adobe.com
> > <ma...@adobe.com>> wrote:
> >
> >     This current proposal no longer requires 72 hour voting.  To me, this
> >     means that we could eventually automate releasing to the point where
> the
> >     CI prepares a set of packages with MD5 sums separately prepares a
> report
> >     of all new files and all files with changes to the headers.
> >
> >     The RM then runs another tool that downloads the packages, verifies
> the
> >     MD5, signs with the PGP key (yes, the RM has to type in their
> password)
> >     and uploads it to the RC server.
> >
> >     Then three folks run another tool that downloads the packages,
> verifies
> >     signatures, expands the source package, runs RAT, downloads an SCM
> tag,
> >     compares the source against the tag, runs the default ant or maven
> >     target,
> >     and prepares a report with the LICENSE and NOTICE files and headers
> >     of new
> >     files and changed headers and RAT output.
> >
> >     As soon as three folks vote +1 and there are not more -1's, another
> tool
> >     is run to push it to the release server.
> >
> >     Would this meet requirements and be acceptable?
> >
> >     What if a machine did the downloading of packages, signature
> >     verification,
> >     RAT, SCM compare and build so the voters only need to review a report
> >     before voting.  Would that also meet requirements and be acceptable?
> >
> >     Thanks,
> >     -Alex
> >
> >     On 5/23/14 8:43 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
> >
> >     >People perform releases. They can use whatever tools
> >     >they want, but at the end, the only validation check
> >     >that really matters are those PMC members who test,
> >     >validate and +1 the release.
> >     >
> >     >For example, let's say that there is a codebase that
> >     >doesn't pass some test, but get's the required 3 +1s
> >     >for release and the RM doesn't pull it. Even though
> >     >according to the CI (or whatever) it's "not a release"
> >     >(it failed), as far as the PMC and the ASF is concerned,
> >     >it IS a release.
> >     >
> >     >Conversely, no matter what a CI may test, package and
> >     >drop off somewhere, if it's not voted on, it's not
> >     >a release.
> >     >
> >     >On May 23, 2014, at 11:33 AM, Brian LeRoux <b@brian.io
> >     <ma...@brian.io>> wrote:
> >     >
> >     >> C'mon Sebb. This is circular false logic.
> >     >>
> >     >> On May 23, 2014 10:29 AM, "sebb" <sebbaz@gmail.com
> >     <ma...@gmail.com>> wrote:
> >     >> On 23 May 2014 16:01, Brian LeRoux <b@brian.io
> >     <ma...@brian.io>> wrote:
> >     >> > @mark agree, there are many layers to the stated legal
> >     perception and
> >     >>indeed
> >     >> > most other OSS projects do not require a VOTE. It was
> >     communicated to
> >     >>me
> >     >> > that the VOTE specifically mitigated risk to the releasing
> >     individual
> >     >> > (publishing artifacts to ./dist). This, and human error, are
> >     >>mitigated by
> >     >> > not using humans to perform those actions susceptible to human
> >     error.
> >     >>That
> >     >> > is the point of a CI system and automated builds. All the
> >     actions of a
> >     >> > release could be done by a machine and ensuring the policy will
> >     allow
> >     >>that
> >     >> > is what I'm looking for.
> >     >>
> >     >> However, the CI and automated build systems are created by
> fallible
> >     >>humans.
> >     >>
> >     >> This is why it is important to ensure that the release vote
> contains
> >     >> sufficient details for an independent check of the source release
> >     >> contents against the SCM tag.
> >     >>
> >     >> >
> >     >> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg
> >     <struberg@yahoo.de <ma...@yahoo.de>>
> >     >>wrote:
> >     >> >>
> >     >> >> Brian, we only specifically talked about whether we should be
> >     >>allowed to
> >     >> >> give_intermediate_ build artifacts like nightly builds, etc to
> >     >>interested
> >     >> >> people. I personally find it a bit too restrictive to not
> allow to
> >     >>publish
> >     >> >> those for user testing. We (the foundation) already do this
> >     via our
> >     >> >> snapshots maven repos...
> >     >> >>
> >     >> >> And there are also different layers of 'legal'. There is no
> law in
> >     >>the US
> >     >> >> nor otherwhere in the world who requires a VOTE before an
> >     opensource
> >     >> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
> >     >> >>
> >     >> >> BUT: it is an ASF policy and thus binding for all our projects
> to
> >     >>VOTE on
> >     >> >> releases.
> >     >> >> And it is a really good one as it increases the technical and
> >     legal
> >     >> >> quality of our products! It's really a good thing to have 10+
> >     people
> >     >>looking
> >     >> >> at a release and e.g. discovering that a file has the wrong
> >     license
> >     >>and
> >     >> >> should get removed again for example. And of course it helps
> >     >>reducing the
> >     >> >> risk from getting sued because we obviously try to minimize
> human
> >     >>errors.
> >     >> >>
> >     >> >> @Shane I'm not sure how many ASF members are subscribed to the
> >     legal
> >     >>list,
> >     >> >> maybe it is enough if we just rise awareness.
> >     >> >>
> >     >> >> LieGrue,
> >     >> >> strub
> >     >> >>
> >     >> >>
> >     >> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b@brian.io
> >     <ma...@brian.io>> wrote:
> >     >> >>
> >     >> >>
> >     >> >>
> >     >> >>
> >     >> >>
> >     >> >> "But the point already got covered and answered dozens of
> >     times imo.
> >     >>The
> >     >> >> answer is that the ALv2 protects the foundation and also the
> >     release
> >     >>manager
> >     >> >> already for all bona fides cases. End of story."
> >     >> >>
> >     >> >>
> >     >> >> Interesting for myself to note that it was communicated very
> >     >>directly to
> >     >> >> Cordova that this *was not* the case. Votes are a necessary
> >     >>component for a
> >     >> >> valid (aka legal) release. Also interesting for me to discover
> in
> >     >>this
> >     >> >> thread that the release policy is not adhered to by all ASF
> >     >>projects. We
> >     >> >> were lead to believe the rules are immutable, all projects obey
> >     >>them. End of
> >     >> >> story.
> >     >> >>
> >     >> >> I am dismayed to discover this is not the case and Cordova was
> >     >>singled
> >     >> >> out.
> >     >> >>
> >     >> >> However, clarity here is a great starting to amending the
> >     rules, and
> >     >>I
> >     >> >> recognize this effort is not forum for that. My perspective:
> the
> >     >>vote is a
> >     >> >> SHOULD and most certainly SHA verifciation SHOULD be the job
> of a
> >     >>computer
> >     >> >> (aka CI system) and not a human and I am very happy to hear
> >     there is
> >     >> >> precedent for this with other projects.
> >     >> >>
> >     >> >>
> >     >> >>
> >     >> >>
> >     >> >
> >     >>
> >     >>
> ---------------------------------------------------------------------
> >     >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >     <ma...@apache.org>
> >     >> For additional commands, e-mail: legal-discuss-help@apache.org
> >     <ma...@apache.org>
> >     >>
> >     >
> >     >
> >
> >---------------------------------------------------------------------
> >     >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >     <ma...@apache.org>
> >     >For additional commands, e-mail: legal-discuss-help@apache.org
> >     <ma...@apache.org>
> >     >
> >
> >
> >     ---------------------------------------------------------------------
> >     To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >     <ma...@apache.org>
> >     For additional commands, e-mail: legal-discuss-help@apache.org
> >     <ma...@apache.org>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

Re: Release Policy

[Mark Thomas <ma...@apache.org>]

On 23/05/2014 19:33, Brian LeRoux wrote:
> Yes it is as JJ says as long as a vote happens the tools matter not.
> Though why the vote has to happen is yet to be clarified other than
> meandering justifications.

Brian,

How may times and how many people have to repeat this before it sinks in?

The PMC vote makes the release an act of the foundation rather than an
act of the individual release manager. In the unlikely event of $BigCorp
deciding to start a lawsuit over something in the release making the
release an act of the foundation makes the foundation the target of any
such lawsuit rather than the individual release manager.

To put it another way, the vote protects the release manager from being
the target of an expensive lawsuit. Yes the likelihood of this is low.
However the potential impact should this happen is large. Therefore it
is foundation policy that the vote takes place to ensure that release
managers (whether they understand the protection they get from the
process or not) are protected.

Mark


> 
> On May 23, 2014 11:56 AM, "Alex Harui" <aharui@adobe.com
> <ma...@adobe.com>> wrote:
> 
>     This current proposal no longer requires 72 hour voting.  To me, this
>     means that we could eventually automate releasing to the point where the
>     CI prepares a set of packages with MD5 sums separately prepares a report
>     of all new files and all files with changes to the headers.
> 
>     The RM then runs another tool that downloads the packages, verifies the
>     MD5, signs with the PGP key (yes, the RM has to type in their password)
>     and uploads it to the RC server.
> 
>     Then three folks run another tool that downloads the packages, verifies
>     signatures, expands the source package, runs RAT, downloads an SCM tag,
>     compares the source against the tag, runs the default ant or maven
>     target,
>     and prepares a report with the LICENSE and NOTICE files and headers
>     of new
>     files and changed headers and RAT output.
> 
>     As soon as three folks vote +1 and there are not more -1's, another tool
>     is run to push it to the release server.
> 
>     Would this meet requirements and be acceptable?
> 
>     What if a machine did the downloading of packages, signature
>     verification,
>     RAT, SCM compare and build so the voters only need to review a report
>     before voting.  Would that also meet requirements and be acceptable?
> 
>     Thanks,
>     -Alex
> 
>     On 5/23/14 8:43 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
> 
>     >People perform releases. They can use whatever tools
>     >they want, but at the end, the only validation check
>     >that really matters are those PMC members who test,
>     >validate and +1 the release.
>     >
>     >For example, let's say that there is a codebase that
>     >doesn't pass some test, but get's the required 3 +1s
>     >for release and the RM doesn't pull it. Even though
>     >according to the CI (or whatever) it's "not a release"
>     >(it failed), as far as the PMC and the ASF is concerned,
>     >it IS a release.
>     >
>     >Conversely, no matter what a CI may test, package and
>     >drop off somewhere, if it's not voted on, it's not
>     >a release.
>     >
>     >On May 23, 2014, at 11:33 AM, Brian LeRoux <b@brian.io
>     <ma...@brian.io>> wrote:
>     >
>     >> C'mon Sebb. This is circular false logic.
>     >>
>     >> On May 23, 2014 10:29 AM, "sebb" <sebbaz@gmail.com
>     <ma...@gmail.com>> wrote:
>     >> On 23 May 2014 16:01, Brian LeRoux <b@brian.io
>     <ma...@brian.io>> wrote:
>     >> > @mark agree, there are many layers to the stated legal
>     perception and
>     >>indeed
>     >> > most other OSS projects do not require a VOTE. It was
>     communicated to
>     >>me
>     >> > that the VOTE specifically mitigated risk to the releasing
>     individual
>     >> > (publishing artifacts to ./dist). This, and human error, are
>     >>mitigated by
>     >> > not using humans to perform those actions susceptible to human
>     error.
>     >>That
>     >> > is the point of a CI system and automated builds. All the
>     actions of a
>     >> > release could be done by a machine and ensuring the policy will
>     allow
>     >>that
>     >> > is what I'm looking for.
>     >>
>     >> However, the CI and automated build systems are created by fallible
>     >>humans.
>     >>
>     >> This is why it is important to ensure that the release vote contains
>     >> sufficient details for an independent check of the source release
>     >> contents against the SCM tag.
>     >>
>     >> >
>     >> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg
>     <struberg@yahoo.de <ma...@yahoo.de>>
>     >>wrote:
>     >> >>
>     >> >> Brian, we only specifically talked about whether we should be
>     >>allowed to
>     >> >> give_intermediate_ build artifacts like nightly builds, etc to
>     >>interested
>     >> >> people. I personally find it a bit too restrictive to not allow to
>     >>publish
>     >> >> those for user testing. We (the foundation) already do this
>     via our
>     >> >> snapshots maven repos...
>     >> >>
>     >> >> And there are also different layers of 'legal'. There is no law in
>     >>the US
>     >> >> nor otherwhere in the world who requires a VOTE before an
>     opensource
>     >> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
>     >> >>
>     >> >> BUT: it is an ASF policy and thus binding for all our projects to
>     >>VOTE on
>     >> >> releases.
>     >> >> And it is a really good one as it increases the technical and
>     legal
>     >> >> quality of our products! It's really a good thing to have 10+
>     people
>     >>looking
>     >> >> at a release and e.g. discovering that a file has the wrong
>     license
>     >>and
>     >> >> should get removed again for example. And of course it helps
>     >>reducing the
>     >> >> risk from getting sued because we obviously try to minimize human
>     >>errors.
>     >> >>
>     >> >> @Shane I'm not sure how many ASF members are subscribed to the
>     legal
>     >>list,
>     >> >> maybe it is enough if we just rise awareness.
>     >> >>
>     >> >> LieGrue,
>     >> >> strub
>     >> >>
>     >> >>
>     >> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b@brian.io
>     <ma...@brian.io>> wrote:
>     >> >>
>     >> >>
>     >> >>
>     >> >>
>     >> >>
>     >> >> "But the point already got covered and answered dozens of
>     times imo.
>     >>The
>     >> >> answer is that the ALv2 protects the foundation and also the
>     release
>     >>manager
>     >> >> already for all bona fides cases. End of story."
>     >> >>
>     >> >>
>     >> >> Interesting for myself to note that it was communicated very
>     >>directly to
>     >> >> Cordova that this *was not* the case. Votes are a necessary
>     >>component for a
>     >> >> valid (aka legal) release. Also interesting for me to discover in
>     >>this
>     >> >> thread that the release policy is not adhered to by all ASF
>     >>projects. We
>     >> >> were lead to believe the rules are immutable, all projects obey
>     >>them. End of
>     >> >> story.
>     >> >>
>     >> >> I am dismayed to discover this is not the case and Cordova was
>     >>singled
>     >> >> out.
>     >> >>
>     >> >> However, clarity here is a great starting to amending the
>     rules, and
>     >>I
>     >> >> recognize this effort is not forum for that. My perspective: the
>     >>vote is a
>     >> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
>     >>computer
>     >> >> (aka CI system) and not a human and I am very happy to hear
>     there is
>     >> >> precedent for this with other projects.
>     >> >>
>     >> >>
>     >> >>
>     >> >>
>     >> >
>     >>
>     >> ---------------------------------------------------------------------
>     >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>     <ma...@apache.org>
>     >> For additional commands, e-mail: legal-discuss-help@apache.org
>     <ma...@apache.org>
>     >>
>     >
>     >
>     >---------------------------------------------------------------------
>     >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>     <ma...@apache.org>
>     >For additional commands, e-mail: legal-discuss-help@apache.org
>     <ma...@apache.org>
>     >
> 
> 
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>     <ma...@apache.org>
>     For additional commands, e-mail: legal-discuss-help@apache.org
>     <ma...@apache.org>
> 


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

Re: Release Policy

[Brian LeRoux <b...@brian.io>]

Yes it is as JJ says as long as a vote happens the tools matter not. Though
why the vote has to happen is yet to be clarified other than meandering
justifications.
On May 23, 2014 11:56 AM, "Alex Harui" <ah...@adobe.com> wrote:

> This current proposal no longer requires 72 hour voting.  To me, this
> means that we could eventually automate releasing to the point where the
> CI prepares a set of packages with MD5 sums separately prepares a report
> of all new files and all files with changes to the headers.
>
> The RM then runs another tool that downloads the packages, verifies the
> MD5, signs with the PGP key (yes, the RM has to type in their password)
> and uploads it to the RC server.
>
> Then three folks run another tool that downloads the packages, verifies
> signatures, expands the source package, runs RAT, downloads an SCM tag,
> compares the source against the tag, runs the default ant or maven target,
> and prepares a report with the LICENSE and NOTICE files and headers of new
> files and changed headers and RAT output.
>
> As soon as three folks vote +1 and there are not more -1's, another tool
> is run to push it to the release server.
>
> Would this meet requirements and be acceptable?
>
> What if a machine did the downloading of packages, signature verification,
> RAT, SCM compare and build so the voters only need to review a report
> before voting.  Would that also meet requirements and be acceptable?
>
> Thanks,
> -Alex
>
> On 5/23/14 8:43 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
>
> >People perform releases. They can use whatever tools
> >they want, but at the end, the only validation check
> >that really matters are those PMC members who test,
> >validate and +1 the release.
> >
> >For example, let's say that there is a codebase that
> >doesn't pass some test, but get's the required 3 +1s
> >for release and the RM doesn't pull it. Even though
> >according to the CI (or whatever) it's "not a release"
> >(it failed), as far as the PMC and the ASF is concerned,
> >it IS a release.
> >
> >Conversely, no matter what a CI may test, package and
> >drop off somewhere, if it's not voted on, it's not
> >a release.
> >
> >On May 23, 2014, at 11:33 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> C'mon Sebb. This is circular false logic.
> >>
> >> On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com> wrote:
> >> On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
> >> > @mark agree, there are many layers to the stated legal perception and
> >>indeed
> >> > most other OSS projects do not require a VOTE. It was communicated to
> >>me
> >> > that the VOTE specifically mitigated risk to the releasing individual
> >> > (publishing artifacts to ./dist). This, and human error, are
> >>mitigated by
> >> > not using humans to perform those actions susceptible to human error.
> >>That
> >> > is the point of a CI system and automated builds. All the actions of a
> >> > release could be done by a machine and ensuring the policy will allow
> >>that
> >> > is what I'm looking for.
> >>
> >> However, the CI and automated build systems are created by fallible
> >>humans.
> >>
> >> This is why it is important to ensure that the release vote contains
> >> sufficient details for an independent check of the source release
> >> contents against the SCM tag.
> >>
> >> >
> >> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de>
> >>wrote:
> >> >>
> >> >> Brian, we only specifically talked about whether we should be
> >>allowed to
> >> >> give_intermediate_ build artifacts like nightly builds, etc to
> >>interested
> >> >> people. I personally find it a bit too restrictive to not allow to
> >>publish
> >> >> those for user testing. We (the foundation) already do this via our
> >> >> snapshots maven repos...
> >> >>
> >> >> And there are also different layers of 'legal'. There is no law in
> >>the US
> >> >> nor otherwhere in the world who requires a VOTE before an opensource
> >> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
> >> >>
> >> >> BUT: it is an ASF policy and thus binding for all our projects to
> >>VOTE on
> >> >> releases.
> >> >> And it is a really good one as it increases the technical and legal
> >> >> quality of our products! It's really a good thing to have 10+ people
> >>looking
> >> >> at a release and e.g. discovering that a file has the wrong license
> >>and
> >> >> should get removed again for example. And of course it helps
> >>reducing the
> >> >> risk from getting sued because we obviously try to minimize human
> >>errors.
> >> >>
> >> >> @Shane I'm not sure how many ASF members are subscribed to the legal
> >>list,
> >> >> maybe it is enough if we just rise awareness.
> >> >>
> >> >> LieGrue,
> >> >> strub
> >> >>
> >> >>
> >> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> "But the point already got covered and answered dozens of times imo.
> >>The
> >> >> answer is that the ALv2 protects the foundation and also the release
> >>manager
> >> >> already for all bona fides cases. End of story."
> >> >>
> >> >>
> >> >> Interesting for myself to note that it was communicated very
> >>directly to
> >> >> Cordova that this *was not* the case. Votes are a necessary
> >>component for a
> >> >> valid (aka legal) release. Also interesting for me to discover in
> >>this
> >> >> thread that the release policy is not adhered to by all ASF
> >>projects. We
> >> >> were lead to believe the rules are immutable, all projects obey
> >>them. End of
> >> >> story.
> >> >>
> >> >> I am dismayed to discover this is not the case and Cordova was
> >>singled
> >> >> out.
> >> >>
> >> >> However, clarity here is a great starting to amending the rules, and
> >>I
> >> >> recognize this effort is not forum for that. My perspective: the
> >>vote is a
> >> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
> >>computer
> >> >> (aka CI system) and not a human and I am very happy to hear there is
> >> >> precedent for this with other projects.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

Re: Release Policy

[Marvin Humphrey <ma...@rectangular.com>]

On Fri, May 23, 2014 at 9:56 AM, Alex Harui <ah...@adobe.com> wrote:
> This current proposal no longer requires 72 hour voting.

On Fri, May 23, 2014 at 10:34 AM, Mark Struberg <st...@yahoo.de> wrote:
> imo we should keep the 72h as mandatory .

The 72 hour voting window being a strong recommendation ("SHOULD")
rather than a hard requirement ("MUST") is not a policy change. That
there is confusion on this point underscores the urgency of codifying
the policy.

Background: http://markmail.org/message/ogkhiwwhjwnwhnjc

Projects considering disregarding the recommendation to use a 72 hour
window would be well-advised to consult with the Board in advance
about the issues covered in that thread, and to keep the Board in the
loop via quarterly reports.

Again: The goal of this initiative is only to clarify policy, NOT TO CHANGE IT.

Marvin Humphrey

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

Re: Release Policy

[Alex Harui <ah...@adobe.com>]

This current proposal no longer requires 72 hour voting.  To me, this
means that we could eventually automate releasing to the point where the
CI prepares a set of packages with MD5 sums separately prepares a report
of all new files and all files with changes to the headers.

The RM then runs another tool that downloads the packages, verifies the
MD5, signs with the PGP key (yes, the RM has to type in their password)
and uploads it to the RC server.

Then three folks run another tool that downloads the packages, verifies
signatures, expands the source package, runs RAT, downloads an SCM tag,
compares the source against the tag, runs the default ant or maven target,
and prepares a report with the LICENSE and NOTICE files and headers of new
files and changed headers and RAT output.

As soon as three folks vote +1 and there are not more -1's, another tool
is run to push it to the release server.

Would this meet requirements and be acceptable?

What if a machine did the downloading of packages, signature verification,
RAT, SCM compare and build so the voters only need to review a report
before voting.  Would that also meet requirements and be acceptable?

Thanks,
-Alex

On 5/23/14 8:43 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:

>People perform releases. They can use whatever tools
>they want, but at the end, the only validation check
>that really matters are those PMC members who test,
>validate and +1 the release.
>
>For example, let's say that there is a codebase that
>doesn't pass some test, but get's the required 3 +1s
>for release and the RM doesn't pull it. Even though
>according to the CI (or whatever) it's "not a release"
>(it failed), as far as the PMC and the ASF is concerned,
>it IS a release.
>
>Conversely, no matter what a CI may test, package and
>drop off somewhere, if it's not voted on, it's not
>a release.
>
>On May 23, 2014, at 11:33 AM, Brian LeRoux <b...@brian.io> wrote:
>
>> C'mon Sebb. This is circular false logic.
>> 
>> On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com> wrote:
>> On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
>> > @mark agree, there are many layers to the stated legal perception and
>>indeed
>> > most other OSS projects do not require a VOTE. It was communicated to
>>me
>> > that the VOTE specifically mitigated risk to the releasing individual
>> > (publishing artifacts to ./dist). This, and human error, are
>>mitigated by
>> > not using humans to perform those actions susceptible to human error.
>>That
>> > is the point of a CI system and automated builds. All the actions of a
>> > release could be done by a machine and ensuring the policy will allow
>>that
>> > is what I'm looking for.
>> 
>> However, the CI and automated build systems are created by fallible
>>humans.
>> 
>> This is why it is important to ensure that the release vote contains
>> sufficient details for an independent check of the source release
>> contents against the SCM tag.
>> 
>> >
>> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de>
>>wrote:
>> >>
>> >> Brian, we only specifically talked about whether we should be
>>allowed to
>> >> give_intermediate_ build artifacts like nightly builds, etc to
>>interested
>> >> people. I personally find it a bit too restrictive to not allow to
>>publish
>> >> those for user testing. We (the foundation) already do this via our
>> >> snapshots maven repos...
>> >>
>> >> And there are also different layers of 'legal'. There is no law in
>>the US
>> >> nor otherwhere in the world who requires a VOTE before an opensource
>> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
>> >>
>> >> BUT: it is an ASF policy and thus binding for all our projects to
>>VOTE on
>> >> releases.
>> >> And it is a really good one as it increases the technical and legal
>> >> quality of our products! It's really a good thing to have 10+ people
>>looking
>> >> at a release and e.g. discovering that a file has the wrong license
>>and
>> >> should get removed again for example. And of course it helps
>>reducing the
>> >> risk from getting sued because we obviously try to minimize human
>>errors.
>> >>
>> >> @Shane I'm not sure how many ASF members are subscribed to the legal
>>list,
>> >> maybe it is enough if we just rise awareness.
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >>
>> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> "But the point already got covered and answered dozens of times imo.
>>The
>> >> answer is that the ALv2 protects the foundation and also the release
>>manager
>> >> already for all bona fides cases. End of story."
>> >>
>> >>
>> >> Interesting for myself to note that it was communicated very
>>directly to
>> >> Cordova that this *was not* the case. Votes are a necessary
>>component for a
>> >> valid (aka legal) release. Also interesting for me to discover in
>>this
>> >> thread that the release policy is not adhered to by all ASF
>>projects. We
>> >> were lead to believe the rules are immutable, all projects obey
>>them. End of
>> >> story.
>> >>
>> >> I am dismayed to discover this is not the case and Cordova was
>>singled
>> >> out.
>> >>
>> >> However, clarity here is a great starting to amending the rules, and
>>I
>> >> recognize this effort is not forum for that. My perspective: the
>>vote is a
>> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
>>computer
>> >> (aka CI system) and not a human and I am very happy to hear there is
>> >> precedent for this with other projects.
>> >>
>> >>
>> >>
>> >>
>> >
>> 
>> ---------------------------------------------------------------------
>> 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
>


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

Re: Release Policy

[Jim Jagielski <ji...@jaguNET.com>]

People perform releases. They can use whatever tools
they want, but at the end, the only validation check
that really matters are those PMC members who test,
validate and +1 the release.

For example, let's say that there is a codebase that
doesn't pass some test, but get's the required 3 +1s
for release and the RM doesn't pull it. Even though
according to the CI (or whatever) it's "not a release"
(it failed), as far as the PMC and the ASF is concerned,
it IS a release.

Conversely, no matter what a CI may test, package and
drop off somewhere, if it's not voted on, it's not
a release.

On May 23, 2014, at 11:33 AM, Brian LeRoux <b...@brian.io> wrote:

> C'mon Sebb. This is circular false logic.
> 
> On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com> wrote:
> On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
> > @mark agree, there are many layers to the stated legal perception and indeed
> > most other OSS projects do not require a VOTE. It was communicated to me
> > that the VOTE specifically mitigated risk to the releasing individual
> > (publishing artifacts to ./dist). This, and human error, are mitigated by
> > not using humans to perform those actions susceptible to human error. That
> > is the point of a CI system and automated builds. All the actions of a
> > release could be done by a machine and ensuring the policy will allow that
> > is what I'm looking for.
> 
> However, the CI and automated build systems are created by fallible humans.
> 
> This is why it is important to ensure that the release vote contains
> sufficient details for an independent check of the source release
> contents against the SCM tag.
> 
> >
> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de> wrote:
> >>
> >> Brian, we only specifically talked about whether we should be allowed to
> >> give_intermediate_ build artifacts like nightly builds, etc to interested
> >> people. I personally find it a bit too restrictive to not allow to publish
> >> those for user testing. We (the foundation) already do this via our
> >> snapshots maven repos...
> >>
> >> And there are also different layers of 'legal'. There is no law in the US
> >> nor otherwhere in the world who requires a VOTE before an opensource
> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
> >>
> >> BUT: it is an ASF policy and thus binding for all our projects to VOTE on
> >> releases.
> >> And it is a really good one as it increases the technical and legal
> >> quality of our products! It's really a good thing to have 10+ people looking
> >> at a release and e.g. discovering that a file has the wrong license and
> >> should get removed again for example. And of course it helps reducing the
> >> risk from getting sued because we obviously try to minimize human errors.
> >>
> >> @Shane I'm not sure how many ASF members are subscribed to the legal list,
> >> maybe it is enough if we just rise awareness.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
> >>
> >>
> >>
> >>
> >>
> >> "But the point already got covered and answered dozens of times imo. The
> >> answer is that the ALv2 protects the foundation and also the release manager
> >> already for all bona fides cases. End of story."
> >>
> >>
> >> Interesting for myself to note that it was communicated very directly to
> >> Cordova that this *was not* the case. Votes are a necessary component for a
> >> valid (aka legal) release. Also interesting for me to discover in this
> >> thread that the release policy is not adhered to by all ASF projects. We
> >> were lead to believe the rules are immutable, all projects obey them. End of
> >> story.
> >>
> >> I am dismayed to discover this is not the case and Cordova was singled
> >> out.
> >>
> >> However, clarity here is a great starting to amending the rules, and I
> >> recognize this effort is not forum for that. My perspective: the vote is a
> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a computer
> >> (aka CI system) and not a human and I am very happy to hear there is
> >> precedent for this with other projects.
> >>
> >>
> >>
> >>
> >
> 
> ---------------------------------------------------------------------
> 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

Re: Release Policy

[Brian LeRoux <b...@brian.io>]

C'mon Sebb. This is circular false logic.
On May 23, 2014 10:29 AM, "sebb" <se...@gmail.com> wrote:

> On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
> > @mark agree, there are many layers to the stated legal perception and
> indeed
> > most other OSS projects do not require a VOTE. It was communicated to me
> > that the VOTE specifically mitigated risk to the releasing individual
> > (publishing artifacts to ./dist). This, and human error, are mitigated by
> > not using humans to perform those actions susceptible to human error.
> That
> > is the point of a CI system and automated builds. All the actions of a
> > release could be done by a machine and ensuring the policy will allow
> that
> > is what I'm looking for.
>
> However, the CI and automated build systems are created by fallible humans.
>
> This is why it is important to ensure that the release vote contains
> sufficient details for an independent check of the source release
> contents against the SCM tag.
>
> >
> > On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de>
> wrote:
> >>
> >> Brian, we only specifically talked about whether we should be allowed to
> >> give_intermediate_ build artifacts like nightly builds, etc to
> interested
> >> people. I personally find it a bit too restrictive to not allow to
> publish
> >> those for user testing. We (the foundation) already do this via our
> >> snapshots maven repos...
> >>
> >> And there are also different layers of 'legal'. There is no law in the
> US
> >> nor otherwhere in the world who requires a VOTE before an opensource
> >> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
> >>
> >> BUT: it is an ASF policy and thus binding for all our projects to VOTE
> on
> >> releases.
> >> And it is a really good one as it increases the technical and legal
> >> quality of our products! It's really a good thing to have 10+ people
> looking
> >> at a release and e.g. discovering that a file has the wrong license and
> >> should get removed again for example. And of course it helps reducing
> the
> >> risk from getting sued because we obviously try to minimize human
> errors.
> >>
> >> @Shane I'm not sure how many ASF members are subscribed to the legal
> list,
> >> maybe it is enough if we just rise awareness.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
> >>
> >>
> >>
> >>
> >>
> >> "But the point already got covered and answered dozens of times imo. The
> >> answer is that the ALv2 protects the foundation and also the release
> manager
> >> already for all bona fides cases. End of story."
> >>
> >>
> >> Interesting for myself to note that it was communicated very directly to
> >> Cordova that this *was not* the case. Votes are a necessary component
> for a
> >> valid (aka legal) release. Also interesting for me to discover in this
> >> thread that the release policy is not adhered to by all ASF projects. We
> >> were lead to believe the rules are immutable, all projects obey them.
> End of
> >> story.
> >>
> >> I am dismayed to discover this is not the case and Cordova was singled
> >> out.
> >>
> >> However, clarity here is a great starting to amending the rules, and I
> >> recognize this effort is not forum for that. My perspective: the vote
> is a
> >> SHOULD and most certainly SHA verifciation SHOULD be the job of a
> computer
> >> (aka CI system) and not a human and I am very happy to hear there is
> >> precedent for this with other projects.
> >>
> >>
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

Re: Release Policy

[sebb <se...@gmail.com>]

On 23 May 2014 16:01, Brian LeRoux <b...@brian.io> wrote:
> @mark agree, there are many layers to the stated legal perception and indeed
> most other OSS projects do not require a VOTE. It was communicated to me
> that the VOTE specifically mitigated risk to the releasing individual
> (publishing artifacts to ./dist). This, and human error, are mitigated by
> not using humans to perform those actions susceptible to human error. That
> is the point of a CI system and automated builds. All the actions of a
> release could be done by a machine and ensuring the policy will allow that
> is what I'm looking for.

However, the CI and automated build systems are created by fallible humans.

This is why it is important to ensure that the release vote contains
sufficient details for an independent check of the source release
contents against the SCM tag.

>
> On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de> wrote:
>>
>> Brian, we only specifically talked about whether we should be allowed to
>> give_intermediate_ build artifacts like nightly builds, etc to interested
>> people. I personally find it a bit too restrictive to not allow to publish
>> those for user testing. We (the foundation) already do this via our
>> snapshots maven repos...
>>
>> And there are also different layers of 'legal'. There is no law in the US
>> nor otherwhere in the world who requires a VOTE before an opensource
>> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
>>
>> BUT: it is an ASF policy and thus binding for all our projects to VOTE on
>> releases.
>> And it is a really good one as it increases the technical and legal
>> quality of our products! It's really a good thing to have 10+ people looking
>> at a release and e.g. discovering that a file has the wrong license and
>> should get removed again for example. And of course it helps reducing the
>> risk from getting sued because we obviously try to minimize human errors.
>>
>> @Shane I'm not sure how many ASF members are subscribed to the legal list,
>> maybe it is enough if we just rise awareness.
>>
>> LieGrue,
>> strub
>>
>>
>> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
>>
>>
>>
>>
>>
>> "But the point already got covered and answered dozens of times imo. The
>> answer is that the ALv2 protects the foundation and also the release manager
>> already for all bona fides cases. End of story."
>>
>>
>> Interesting for myself to note that it was communicated very directly to
>> Cordova that this *was not* the case. Votes are a necessary component for a
>> valid (aka legal) release. Also interesting for me to discover in this
>> thread that the release policy is not adhered to by all ASF projects. We
>> were lead to believe the rules are immutable, all projects obey them. End of
>> story.
>>
>> I am dismayed to discover this is not the case and Cordova was singled
>> out.
>>
>> However, clarity here is a great starting to amending the rules, and I
>> recognize this effort is not forum for that. My perspective: the vote is a
>> SHOULD and most certainly SHA verifciation SHOULD be the job of a computer
>> (aka CI system) and not a human and I am very happy to hear there is
>> precedent for this with other projects.
>>
>>
>>
>>
>

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

Re: Release Policy

[Jim Jagielski <ji...@jaguNET.com>]

Most other OSS projects are not run the same way the ASF
projects are. Whether or not *they* need/want a vote or
not is moot and immaterial to *our* policy.

On May 23, 2014, at 11:01 AM, Brian LeRoux <b...@brian.io> wrote:

> @mark agree, there are many layers to the stated legal perception and indeed most other OSS projects do not require a VOTE. It was communicated to me that the VOTE specifically mitigated risk to the releasing individual (publishing artifacts to ./dist). This, and human error, are mitigated by not using humans to perform those actions susceptible to human error. That is the point of a CI system and automated builds. All the actions of a release could be done by a machine and ensuring the policy will allow that is what I'm looking for. 
> 
> 
> On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de> wrote:
> Brian, we only specifically talked about whether we should be allowed to give_intermediate_ build artifacts like nightly builds, etc to interested people. I personally find it a bit too restrictive to not allow to publish those for user testing. We (the foundation) already do this via our snapshots maven repos...
> 
> And there are also different layers of 'legal'. There is no law in the US nor otherwhere in the world who requires a VOTE before an opensource release. JBoss doesn't do it, Eclipse doesn't do it, etc. 
> 
> BUT: it is an ASF policy and thus binding for all our projects to VOTE on releases. 
> And it is a really good one as it increases the technical and legal quality of our products! It's really a good thing to have 10+ people looking at a release and e.g. discovering that a file has the wrong license and should get removed again for example. And of course it helps reducing the risk from getting sued because we obviously try to minimize human errors. 
> 
> @Shane I'm not sure how many ASF members are subscribed to the legal list, maybe it is enough if we just rise awareness.
> 
> LieGrue,
> strub
> 
> 
> On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
> 
> 
> 
> 
> "But the point already got covered and answered dozens of times imo. The answer is that the ALv2 protects the foundation and also the release manager already for all bona fides cases. End of story."
> 
> 
> Interesting for myself to note that it was communicated very directly to Cordova that this *was not* the case. Votes are a necessary component for a valid (aka legal) release. Also interesting for me to discover in this thread that the release policy is not adhered to by all ASF projects. We were lead to believe the rules are immutable, all projects obey them. End of story. 
> 
> I am dismayed to discover this is not the case and Cordova was singled out. 
> 
> However, clarity here is a great starting to amending the rules, and I recognize this effort is not forum for that. My perspective: the vote is a SHOULD and most certainly SHA verifciation SHOULD be the job of a computer (aka CI system) and not a human and I am very happy to hear there is precedent for this with other projects.
> 
> 
> ​
> 
> 
> 


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

Re: Release Policy

[Brian LeRoux <b...@brian.io>]

@mark agree, there are many layers to the stated legal perception and
indeed most other OSS projects do not require a VOTE. It was communicated
to me that the VOTE specifically mitigated risk to the releasing individual
(publishing artifacts to ./dist). This, and human error, are mitigated by
not using humans to perform those actions susceptible to human error. That
is the point of a CI system and automated builds. All the actions of a
release could be done by a machine and ensuring the policy will allow that
is what I'm looking for.


On Thu, May 22, 2014 at 11:55 PM, Mark Struberg <st...@yahoo.de> wrote:

> Brian, we only specifically talked about whether we should be allowed to
> give_intermediate_ build artifacts like nightly builds, etc to interested
> people. I personally find it a bit too restrictive to not allow to publish
> those for user testing. We (the foundation) already do this via our
> snapshots maven repos...
>
> And there are also different layers of 'legal'. There is no law in the US
> nor otherwhere in the world who requires a VOTE before an opensource
> release. JBoss doesn't do it, Eclipse doesn't do it, etc.
>
> BUT: it is an ASF policy and thus binding for all our projects to VOTE on
> releases.
> And it is a really good one as it increases the technical and legal
> quality of our products! It's really a good thing to have 10+ people
> looking at a release and e.g. discovering that a file has the wrong license
> and should get removed again for example. And of course it helps reducing
> the risk from getting sued because we obviously try to minimize human
> errors.
>
> @Shane I'm not sure how many ASF members are subscribed to the legal list,
> maybe it is enough if we just rise awareness.
>
> LieGrue,
> strub
>
>
>   On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
>
>
>
>
>
> "But the point already got covered and answered dozens of times imo. The
> answer is that the ALv2 protects the foundation and also the release
> manager already for all bona fides cases. End of story."
>
>
> Interesting for myself to note that it was communicated very directly to
> Cordova that this *was not* the case. Votes are a necessary component for a
> valid (aka legal) release. Also interesting for me to discover in this
> thread that the release policy is not adhered to by all ASF projects. We
> were lead to believe the rules are immutable, all projects obey them. End
> of story.
>
> I am dismayed to discover this is not the case and Cordova was singled
> out.
>
> However, clarity here is a great starting to amending the rules, and I
> recognize this effort is not forum for that. My perspective: the vote is a
> SHOULD and most certainly SHA verifciation SHOULD be the job of a computer
> (aka CI system) and not a human and I am very happy to hear there is
> precedent for this with other projects.
>
>
> ​
>
>
>

Re: Release Policy

[Mark Struberg <st...@yahoo.de>]

Brian, we only specifically talked about whether we should be allowed to give_intermediate_ build artifacts like nightly builds, etc to interested people. I personally find it a bit too restrictive to not allow to publish those for user testing. We (the foundation) already do this via our snapshots maven repos...


And there are also different layers of 'legal'. There is no law in the US nor otherwhere in the world who requires a VOTE before an opensource release. JBoss doesn't do it, Eclipse doesn't do it, etc. 


BUT: it is an ASF policy and thus binding for all our projects to VOTE on releases. 
And it is a really good one as it increases the technical and legal quality of our products! It's really a good thing to have 10+ people looking at a release and e.g. discovering that a file has the wrong license and should get removed again for example. And of course it helps reducing the risk from getting sued because we obviously try to minimize human errors. 


@Shane I'm not sure how many ASF members are subscribed to the legal list, maybe it is enough if we just rise awareness.


LieGrue,
strub



On Thursday, 22 May 2014, 23:19, Brian LeRoux <b...@brian.io> wrote:
 

>
>
>
>
>"But the
 point already got covered and answered dozens of times imo. The answer 
is that the ALv2 protects the foundation and also the release manager 
already for all bona fides cases. End of story."
>
>Interesting for myself to note that it was communicated very directly to Cordova that this *was not* the case. Votes are a necessary component for a valid (aka legal) release. Also interesting for me to discover in this thread that the release policy is not adhered to by all ASF projects. We were lead to believe the rules are immutable, all projects obey them. End of story. 
>
>I am dismayed to discover this is not the case and Cordova was singled out. 
>
>However, clarity here is a great starting to amending the rules, and I recognize this effort is not forum for that. My perspective: the vote is a SHOULD and most certainly SHA verifciation SHOULD be the job of a computer (aka CI system) and not a human and I am very happy to hear there is precedent for this with other projects. 
>
>
>​
>
>

Re: Release Policy

[Brian LeRoux <b...@brian.io>]

"But the point already got covered and answered dozens of times imo. The
answer is that the ALv2 protects the foundation and also the release
manager already for all bona fides cases. End of story."

Interesting for myself to note that it was communicated very directly to
Cordova that this *was not* the case. Votes are a necessary component for a
valid (aka legal) release. Also interesting for me to discover in this
thread that the release policy is not adhered to by all ASF projects. We
were lead to believe the rules are immutable, all projects obey them. End
of story.

I am dismayed to discover this is not the case and Cordova was singled out.

However, clarity here is a great starting to amending the rules, and I
recognize this effort is not forum for that. My perspective: the vote is a
SHOULD and most certainly SHA verifciation SHOULD be the job of a computer
(aka CI system) and not a human and I am very happy to hear there is
precedent for this with other projects.

​

Re: Release Policy

[Mark Struberg <st...@yahoo.de>]

> I disagree. One of the primary reasons for the release policy being
> defined as it is is to provide a degree of legal protection to the
> release managers.

Oki this is a part which we can discuss on the legal list. But the point already got covered and answered dozens of times imo. The answer is that the ALv2 protects the foundation and also the release manager already for all bona fides cases. End of story. 

Otoh if someone acts mala fide and e.g willingly adds a backdoor to some of our code and releases it then he can be sued (if you can prove the fact) - but even then this has nothing to do if the link to our public repo got shared on a dev@a.o list or a users@a.o list...



Don't get me wrong - cleaning up and getting our release policy straight is an important thing. But imo it's more a question of the policy we *like* to set and not so much about legal rules which do bind us and we need to take care of.


LieGrue,
strub




> On Thursday, 22 May 2014, 22:32, Mark Thomas <ma...@apache.org> wrote:
> > On 22/05/2014 21:27, Mark Struberg wrote:
>> 
>> 
>>  On Thursday, 22 May 2014, 21:56, Marvin Humphrey 
> <ma...@rectangular.com> wrote:
>>>  *  board@apache is private, and this should be discussed in public.
>>>  *   The Legal Affairs committee is being asked to curate the policy.
>>>  *  dev@community.apache.org would have been another possibility, but is 
> not
>>>      where Legal Affairs does business.
>> 
>> 
>> 
>>  But this has nothing to do with Legal Affairs. I don't see any legal 
> question around.
>>  This is more something for the members list imo. This has nothing to do 
> with a discussion about a legal question but really is 'only' a policy 
> thingy imo.
> 
> I disagree. One of the primary reasons for the release policy being
> defined as it is is to provide a degree of legal protection to the
> release managers. The idea is that if something goes wrong and lawsuits
> start flying because of something in a release it is the ASF rather than
> the release manager that is the target of those lawsuits. That
> protection kicks in because the release policy ensures that releases are
> an act of the foundation rather than an act of an individual. Therefore,
> it makes sense to me that this is on legal-discuss.
> 
> Mark
> 
> 
> 
> ---------------------------------------------------------------------
> 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

Re: Release Policy

[Mark Thomas <ma...@apache.org>]

On 22/05/2014 21:27, Mark Struberg wrote:
> 
> 
> On Thursday, 22 May 2014, 21:56, Marvin Humphrey <ma...@rectangular.com> wrote:
>> *  board@apache is private, and this should be discussed in public.
>> *   The Legal Affairs committee is being asked to curate the policy.
>> *  dev@community.apache.org would have been another possibility, but is not
>>     where Legal Affairs does business.
> 
> 
> 
> But this has nothing to do with Legal Affairs. I don't see any legal question around.
> This is more something for the members list imo. This has nothing to do with a discussion about a legal question but really is 'only' a policy thingy imo.

I disagree. One of the primary reasons for the release policy being
defined as it is is to provide a degree of legal protection to the
release managers. The idea is that if something goes wrong and lawsuits
start flying because of something in a release it is the ASF rather than
the release manager that is the target of those lawsuits. That
protection kicks in because the release policy ensures that releases are
an act of the foundation rather than an act of an individual. Therefore,
it makes sense to me that this is on legal-discuss.

Mark


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

Re: Release Policy

[Mark Struberg <st...@yahoo.de>]

On Thursday, 22 May 2014, 21:56, Marvin Humphrey <ma...@rectangular.com> wrote:
>*  board@apache is private, and this should be discussed in public.
>*   The Legal Affairs committee is being asked to curate the policy.
>*  dev@community.apache.org would have been another possibility, but is not
>    where Legal Affairs does business.



But this has nothing to do with Legal Affairs. I don't see any legal question around.
This is more something for the members list imo. This has nothing to do with a discussion about a legal question but really is 'only' a policy thingy imo.


LieGrue,
strub

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

Re: Release Policy

[Jim Jagielski <ji...@jaguNET.com>]

On May 22, 2014, at 3:55 PM, Marvin Humphrey <ma...@rectangular.com> wrote:

> On Thu, May 22, 2014 at 11:55 AM, Mark Struberg <st...@yahoo.de> wrote:
>> basically a good idea, but
> 
> :)
> 
>> a.) why is this on legal-discuss?
> 
> *   board@apache is private, and this should be discussed in public.
> *   The Legal Affairs committee is being asked to curate the policy.
> *   dev@community.apache.org would have been another possibility, but is not
>    where Legal Affairs does business.

I think legal-discuss@ is fine and makes a lot of sense.

A Release is a formal, official and *legal* action.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

Re: Release Policy

[Andrea Pescetti <pe...@apache.org>]

On 22/05/2014 Mark Struberg wrote:
> of course, for 'end-users' it makes not much sense to use snapshots. But
> there is also a huge difference between the people reading the
> openwebbeans user list and the OpenOffice user list.

Yes, but in the case of OpenOffice we reinterpret some of the 
assumptions in the policy: the policy (as it is written) implies for 
simplicity that "(people active in the) community" = "dev list" and that 
"testers" = "developers".

But "developers", as already clarified on board list discussions, should 
not be interpreted strictly. It's more like "the project community" (so, 
OpenOffice has a dedicated QA mailing list for testers; and those 
testers are not developers, strictly speaking, and in many cases they 
are not even subscribed to the dev list; but still they are the main 
target public of our snapshots builds).

So this could be the occasion to replace "developer community" by 
"project community", since that's what is meant there. Of course, the 
current wording can stay too, and OpenOffice will continue to interpret 
it as it does currently.

Regards,
   Andrea.

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

Re: Release Policy

[Mark Struberg <st...@yahoo.de>]

again: you need to distinguish between project developers, tool-users and 'end-users'

of course, for 'end-users' it makes not much sense to use snapshots. But there is also a huge difference between the people reading the openwebbeans user list and the OpenOffice user list. It's often just not convenient for bigger projects to tell people to go build it themselfs. 

In most of the projects I'm involved in (about a dozen) we let Jenkins deploy nightly builds to our public Apache snapshots repo [1]. And this repo IS public...

I really see no problem with this.

LieGrue,
strub




[1] https://repository.apache.org/content/groups/snapshots/

On Thursday, 22 May 2014, 21:56, Marvin Humphrey <ma...@rectangular.com> wrote:
 

>
>
>On Thu, May 22, 2014 at 11:55 AM, Mark Struberg <st...@yahoo.de> wrote:
>> basically a good idea, but
>
>:)
>
>> a.) why is this on legal-discuss?
>
>*  board@apache is private, and this should be discussed in public.
>*   The Legal Affairs committee is being asked to curate the policy.
>*  dev@community.apache.org would have been another possibility, but is not
>    where Legal Affairs does business.
>
>> 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...)
>
>That's the existing policy.
>
>    http://www.apache.org/dev/release.html#what
>
>    Releases are, by definition, anything that is published beyond the group
>    that owns it. In our case, that means any publication outside the group of
>    people on the product dev list. If the general public is being instructed
>    to download a package, then that package has been released. Each PMC must
>    obey the ASF requirements on approving any release. How you label the
>    package is a secondary issue, described below.
>
>    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.
>
>The fact that you are inspired to object only now demonstrates how badly we
>need policy clarification.
>
>
>Marvin Humphrey
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>For additional commands, e-mail: legal-discuss-help@apache.org
>
>
>
>

Re: Release Policy

[Marvin Humphrey <ma...@rectangular.com>]

On Thu, May 22, 2014 at 11:55 AM, Mark Struberg <st...@yahoo.de> wrote:
> basically a good idea, but

:)

> a.) why is this on legal-discuss?

*   board@apache is private, and this should be discussed in public.
*   The Legal Affairs committee is being asked to curate the policy.
*   dev@community.apache.org would have been another possibility, but is not
    where Legal Affairs does business.

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

That's the existing policy.

    http://www.apache.org/dev/release.html#what

    Releases are, by definition, anything that is published beyond the group
    that owns it. In our case, that means any publication outside the group of
    people on the product dev list. If the general public is being instructed
    to download a package, then that package has been released. Each PMC must
    obey the ASF requirements on approving any release. How you label the
    package is a secondary issue, described below.

    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.

The fact that you are inspired to object only now demonstrates how badly we
need policy clarification.

Marvin Humphrey

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

Re: Release Policy

[Mark Struberg <st...@yahoo.de>]

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

Re: Release Policy

[Mark Thomas <ma...@apache.org>]

On 22/05/2014 19:42, Marvin Humphrey 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.

+1. I think this is an excellent initiative.

Comments on the draft in-line.

<snip/>

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

I like the "subscribed to the dev list" definition because it is short
and unambiguous.

However, I think the developer community is a little wider than that.
For example a user who reports a bug and then offers to test the fix
becomes a (temporary) part of the dev community but they might never
subscribe to the dev list.

My best suggestion is to extend dev community to anyone who interacts
with a development resource (dev list, review board, ci system, issue
tracker, etc.).

The important part of this is the "published beyond bit". As long as
someone has to knowingly go past a clear "You are now leaving the user
community. Welcome to the dev community." sign of some form I think we
are fine. The issue is when developer resources (e.g. a CI build) are
advertised directly to the users list or linked to from the product
downloads page etc. (linking from a dev resources page would be fine in
my view).

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

That is a big ask for some projects. In particular I am thinking of
OpenOffice. I'm wondering if there is an alternative form of words -
something like "validate that the binary package is the result of
compilation from the source package" that would allow folks to validate
that the CI system did the right thing with the right inputs to generate
the binaries.

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

Again, I'd be a little more relaxed here. For example the above would
prevent a project creating a developer resources page and linking to the
CI builds from that. That seems overly restrictive.

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

Define test. The Tomcat project uses the TCK (where it has it) to test
releases but we can't make that available to end users.

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

Probably want to add something about only latest releases being on dist.
It is hard to come up with a hard and fast rule since projects use
different versioning schemes.

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

Overall I like this a lot. There are a few areas where I think some
tweaks are required but this draft is pretty much in line with my
understanding of the release policy.

Mark


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

Re: Release Policy

[Justin Mclean <ju...@classsoftware.com>]

Hi,

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

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

We do need to sometimes point non-developers to a nightly release so that they can confirm that a JIRA bug they have raised has been fixed, so perhaps change to "people following the dev list or are involved in fixing a bug"? I can think of one or two cases were we pointed someone to the nightly as it fixes a bug they required and they were unwilling to compile form source.

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

Do we need to clarify test here? For the Apache Flex project we don't include the mustella tests in the release as this would add 600Mb to the release and the tests take 8+ hours to run. However developers / users can check out the tests from version control and run if they need - they are tagged for each release. A release is not made unless the tests pass.

>  All artifacts within the directory MUST be signed by a committer, preferably a PMC member.

May want to add "Files such README, RELEASE_NOTES, LICENSE, KEYS MAY be added for convenience"? These files don't need to be signed I assume.

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

RE: Release Policy

[Lawrence Rosen <lr...@rosenlaw.com>]

[Wherever this thread is moved, please consider this.]

Editing a draft policy through email in this way is very confusing. 

A few days ago I copied Marvin's original proposal to Google Docs and made
some easy changes and comments. Why don't we try using a tool like that to
edit this policy? You can do the same....

See
https://docs.google.com/document/d/1Qpiqdgw2PxAZPMS32I-Y2KR1m-6bIXaOlpMPlcYz
vek/edit?usp=sharing. I've shared this document with everyone who receives
this link. Marvin or someone else should probably create his own master
copy, but otherwise edit away!

/Larry

-----Original Message-----
From: Mark Struberg [mailto:struberg@yahoo.de] 
Sent: Saturday, May 24, 2014 7:09 AM
To: legal-discuss@apache.org
Subject: Re: Release Policy

Plus I think Ross meant to thank Marvin for pushing the release policy
clarifcations.
I'd like to second that!


Imo the following points are not yet clear

* what does 'release' mean in the proposal.
 + are there different 'release' terms in the proposal?

* is the 72h a MUST or SHOULD.

* are we allowed to do snapshot builds for the public?
 + do we need to do this via a special (even more) exclusion of liability?


Please add more and let's split those into own threads.


LieGrue,
strub




On Saturday, 24 May 2014, 15:31, sebb <se...@gmail.com> wrote:


>
>
>There are two "Mark"s who have contributed to this thread.
>This thread is already quite difficult to follow, so please could 
>authors indicate which Mark is being referenced?
>Thanks.
>
>> On May 24, 2014 2:22 AM, "Ross Gardler" <rg...@opendirective.com>
wrote:
>>>
>>> Mark, first of all thank you for delivering on your promise at 
>>> ApacheCon :-D

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

Re: Release Policy

[Rob Weir <ro...@apache.org>]

On Mon, May 26, 2014 at 9:12 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Sat, May 24, 2014 at 7:08 AM, Mark Struberg <st...@yahoo.de> wrote:
>> Imo the following points are not yet clear
>>
>> * what does 'release' mean in the proposal.
>>  + are there different 'release' terms in the proposal?
>
> The release definition section in the draft is closely derived from the "What
> is a Release?" FAQ at <http://www.apache.org/dev/release.html#what>.
>
> You are welcome to propose modifications, though I think it would be dicey
> to stray much from what's on the current policy page.
>
>> * is the 72h a MUST or SHOULD.
>
> Note "should":
>
>     http://www.apache.org/foundation/voting.html
>

+1.  For example, I recall a security patch that had an urgency that
lead to its release with a less than 72-hour vote.

Since that is sometimes the real world, it is worth considering
release policy as a whole with respect to how a PMC reacts to a
zero-day vulnerability or a vulnerability facing imminent disclosure.
 It should not be the focus of policy, IMHO, but there should be a
clear ability for a PMC to do what is needed in such situations,
without abusing the underlying goals of the release policy.

-Rob

>     Votes should generally be permitted to run for at least 72 hours to
>     provide an opportunity for all concerned persons to participate regardless
>     of their geographic locations.
>
>> * are we allowed to do snapshot builds for the public?
>>  + do we need to do this via a special (even more) exclusion of liability?
>
> My fallback on this is to revert the "Publication" section of the proposed
> draft to language extracted verbatim from the current policy page:
>
>     ## Publication ## {#publication}
>
>     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.
>
> That's a bit long for my taste, but if this section is to be contended, it may
> be the only way forward.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> 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

Re: Release Policy

[Marvin Humphrey <ma...@rectangular.com>]

On Sat, May 24, 2014 at 7:08 AM, Mark Struberg <st...@yahoo.de> wrote:
> Imo the following points are not yet clear
>
> * what does 'release' mean in the proposal.
>  + are there different 'release' terms in the proposal?

The release definition section in the draft is closely derived from the "What
is a Release?" FAQ at <http://www.apache.org/dev/release.html#what>.

You are welcome to propose modifications, though I think it would be dicey
to stray much from what's on the current policy page.

> * is the 72h a MUST or SHOULD.

Note "should":

    http://www.apache.org/foundation/voting.html

    Votes should generally be permitted to run for at least 72 hours to
    provide an opportunity for all concerned persons to participate regardless
    of their geographic locations.

> * are we allowed to do snapshot builds for the public?
>  + do we need to do this via a special (even more) exclusion of liability?

My fallback on this is to revert the "Publication" section of the proposed
draft to language extracted verbatim from the current policy page:

    ## Publication ## {#publication}

    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.

That's a bit long for my taste, but if this section is to be contended, it may
be the only way forward.

Marvin Humphrey

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

Re: Release Policy

[Mark Struberg <st...@yahoo.de>]

Plus I think Ross meant to thank Marvin for pushing the release policy clarifcations.
I'd like to second that!


Imo the following points are not yet clear

* what does 'release' mean in the proposal.
 + are there different 'release' terms in the proposal?

* is the 72h a MUST or SHOULD.

* are we allowed to do snapshot builds for the public?
 + do we need to do this via a special (even more) exclusion of liability?


Please add more and let's split those into own threads.


LieGrue,
strub




On Saturday, 24 May 2014, 15:31, sebb <se...@gmail.com> wrote:


>
>
>There are two "Mark"s who have contributed to this thread.
>This thread is already quite difficult to follow, so please could
>authors indicate which Mark is being referenced?
>Thanks.
>
>> On May 24, 2014 2:22 AM, "Ross Gardler" <rg...@opendirective.com> wrote:
>>>
>>> Mark, first of all thank you for delivering on your promise at ApacheCon
>>> :-D

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

Re: Release Policy

[sebb <se...@gmail.com>]

There are two "Mark"s who have contributed to this thread.
This thread is already quite difficult to follow, so please could
authors indicate which Mark is being referenced?
Thanks.

On 24 May 2014 12:51, Brian LeRoux <b...@brian.io> wrote:
> Being that the purpose of this thread was to seek clarity I won't apologize
> for politely seeking that. >=|
>
> Mark: thank you for your lucid descriptions of what the *actual* reasoning
> for this policy is: a final check of the SRC for legal compliance. This is,
> in my opinion, the most important responsibility for commit rights. I am
> concerned the VOTE assumes this daily role of committer is being ignored (to
> ensure legal compliance) and therefore feel the VOTE is a SHOULD as it is
> added precaution and, in my view, encouraging a sloppy and irresponsible
> committership.
>
> On May 24, 2014 2:22 AM, "Ross Gardler" <rg...@opendirective.com> wrote:
>>
>> Mark, first of all thank you for delivering on your promise at ApacheCon
>> :-D
>>
>> Secondly, apologies if my comment has already been covered. The thread
>> seems to have got bogged down in a repeat of past arguments rather than an
>> effort to improve the policy around those arguments. With my comment I'm
>> trying to avoid that argument and instead provide a concrete suggestion for
>> improvement for your doc. If it has been covered somewhere - sorry for the
>> duplication.
>>
>> In the section on release approval. You state:
>>
>> "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."
>>
>> For me the most important part of voting +1 is that the individual is
>> asserting that they have reviewed the source for compliance with ASF
>> policies. You have this in the last sentence as "verifying that the package
>> meets the requirements of the ASF policy on releases". However, it almost
>> feels like an afterthought rather than the most important part. I would move
>> this to the front of the paragraph and possibly even add "including, but not
>> limited to, verifying license files, notice file, ... as described below."
>>
>> My concern is that because all of the initial steps in your current
>> version can be automated it can be argued they are unnecessary. However,
>> verifying the notice files, license files, upstream dependency licenses etc.
>> cannot be reliably automated. Hence we need 3 +1's to indicate that at least
>> 3 people have verified these items and thus the ASF can demonstrate that to
>> the best of the foundations knowledge the release is legally sound. If it
>> can be shown that people voting +1 did not perform these checks then the
>> foundations position is weakened, whereas not building on a local machine is
>> far less damaging from a legal perspective.
>>
>> I would even consider making the part about meeting the requirements of
>> the ASF policy a MUST and the other items a SHOULD.
>>
>> Ross
>>
>>
>>
>>
>>
>>
>>
>> On 22 May 2014 11:42, Marvin Humphrey <ma...@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
>>>
>>
>

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

Re: Release Policy

[Brian LeRoux <b...@brian.io>]

Being that the purpose of this thread was to seek clarity I won't apologize
for politely seeking that. >=|

Mark: thank you for your lucid descriptions of what the *actual* reasoning
for this policy is: a final check of the SRC for legal compliance. This is,
in my opinion, the most important responsibility for commit rights. I am
concerned the VOTE assumes this daily role of committer is being ignored
(to ensure legal compliance) and therefore feel the VOTE is a SHOULD as it
is added precaution and, in my view, encouraging a sloppy and irresponsible
committership.
On May 24, 2014 2:22 AM, "Ross Gardler" <rg...@opendirective.com> wrote:

> Mark, first of all thank you for delivering on your promise at ApacheCon
> :-D
>
> Secondly, apologies if my comment has already been covered. The thread
> seems to have got bogged down in a repeat of past arguments rather than an
> effort to improve the policy around those arguments. With my comment I'm
> trying to avoid that argument and instead provide a concrete suggestion for
> improvement for your doc. If it has been covered somewhere - sorry for the
> duplication.
>
> In the section on release approval. You state:
>
> "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."
>
> For me the most important part of voting +1 is that the individual is
> asserting that they have reviewed the source for compliance with ASF
> policies. You have this in the last sentence as "verifying that the package
> meets the requirements of the ASF policy on releases". However, it almost
> feels like an afterthought rather than the most important part. I would
> move this to the front of the paragraph and possibly even add "including,
> but not limited to, verifying license files, notice file, ... as described
> below."
>
> My concern is that because all of the initial steps in your current
> version can be automated it can be argued they are unnecessary. However,
> verifying the notice files, license files, upstream dependency licenses
> etc. cannot be reliably automated. Hence we need 3 +1's to indicate that at
> least 3 people have verified these items and thus the ASF can demonstrate
> that to the best of the foundations knowledge the release is legally sound.
> If it can be shown that people voting +1 did not perform these checks then
> the foundations position is weakened, whereas not building on a local
> machine is far less damaging from a legal perspective.
>
> I would even consider making the part about meeting the requirements of
> the ASF policy a MUST and the other items a SHOULD.
>
> Ross
>
>
>
>
>
>
>
> On 22 May 2014 11:42, Marvin Humphrey <ma...@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` <http://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
>>
>>
>

Re: Release Policy

[Ross Gardler <rg...@opendirective.com>]

As has been pointed out I meant *Marvin* - he knew what kind of a thread he
was getting himself into when he undertook this work. We owe him a debt of
gratitude.

Of course, there are plenty of others helping here too - thanks to them
also.

Ross







On 24 May 2014 00:21, Ross Gardler <rg...@opendirective.com> wrote:

> Mark, first of all thank you for delivering on your promise at ApacheCon
> :-D
>
> Secondly, apologies if my comment has already been covered. The thread
> seems to have got bogged down in a repeat of past arguments rather than an
> effort to improve the policy around those arguments. With my comment I'm
> trying to avoid that argument and instead provide a concrete suggestion for
> improvement for your doc. If it has been covered somewhere - sorry for the
> duplication.
>
> In the section on release approval. You state:
>
> "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."
>
> For me the most important part of voting +1 is that the individual is
> asserting that they have reviewed the source for compliance with ASF
> policies. You have this in the last sentence as "verifying that the package
> meets the requirements of the ASF policy on releases". However, it almost
> feels like an afterthought rather than the most important part. I would
> move this to the front of the paragraph and possibly even add "including,
> but not limited to, verifying license files, notice file, ... as described
> below."
>
> My concern is that because all of the initial steps in your current
> version can be automated it can be argued they are unnecessary. However,
> verifying the notice files, license files, upstream dependency licenses
> etc. cannot be reliably automated. Hence we need 3 +1's to indicate that at
> least 3 people have verified these items and thus the ASF can demonstrate
> that to the best of the foundations knowledge the release is legally sound.
> If it can be shown that people voting +1 did not perform these checks then
> the foundations position is weakened, whereas not building on a local
> machine is far less damaging from a legal perspective.
>
> I would even consider making the part about meeting the requirements of
> the ASF policy a MUST and the other items a SHOULD.
>
> Ross
>
>
>
>
>
>
>
> On 22 May 2014 11:42, Marvin Humphrey <ma...@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` <http://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
>>
>>
>

Re: Release Policy

[Ross Gardler <rg...@opendirective.com>]

Mark, first of all thank you for delivering on your promise at ApacheCon :-D

Secondly, apologies if my comment has already been covered. The thread
seems to have got bogged down in a repeat of past arguments rather than an
effort to improve the policy around those arguments. With my comment I'm
trying to avoid that argument and instead provide a concrete suggestion for
improvement for your doc. If it has been covered somewhere - sorry for the
duplication.

In the section on release approval. You state:

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

For me the most important part of voting +1 is that the individual is
asserting that they have reviewed the source for compliance with ASF
policies. You have this in the last sentence as "verifying that the package
meets the requirements of the ASF policy on releases". However, it almost
feels like an afterthought rather than the most important part. I would
move this to the front of the paragraph and possibly even add "including,
but not limited to, verifying license files, notice file, ... as described
below."

My concern is that because all of the initial steps in your current version
can be automated it can be argued they are unnecessary. However, verifying
the notice files, license files, upstream dependency licenses etc. cannot
be reliably automated. Hence we need 3 +1's to indicate that at least 3
people have verified these items and thus the ASF can demonstrate that to
the best of the foundations knowledge the release is legally sound. If it
can be shown that people voting +1 did not perform these checks then the
foundations position is weakened, whereas not building on a local machine
is far less damaging from a legal perspective.

I would even consider making the part about meeting the requirements of the
ASF policy a MUST and the other items a SHOULD.

Ross







On 22 May 2014 11:42, Marvin Humphrey <ma...@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
>
>