www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Clarified Release Policy
Date Sun, 25 May 2014 04:24:04 GMT
On Thu, May 22, 2014 at 1:28 PM, Mark Thomas <markt@apache.org> wrote:
>> ## 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.

That's the current definition; the meaning is not altered by the superficial
rephrasing in the proposed draft.


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

In my view it would be best to avoid messing with the existing meaning.  The
current definition has proven workable over time; those who require
clarification can go to the Board, as OpenOffice has done.  Changing the
meaning now would be a contentious policy decision, and thus outside the scope
of this initiative.

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

Working out generalized rules for utilizing CI is likewise a policy change.
Looking to the future, I am personally in favor of exploring the possibilities
afforded by CI, but that's not feasible within the scope of this initiative.

In the meantime, the current policy has proven workable.  Those who want
exceptions granted can do what OpenOffice did: work closely and cooperatively
with the Board.

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

My interpretation of this passage (which has not changed)...

    [...] sufficient for the user to build and test the release provided they
    have access to the appropriate platform and tools.

... is that it is compatible with the TCKs we have access to.

I favor modifying that passage per Ross's suggestion, but I don't believe the
word "test" is problematic.

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

Yes, it's hard to specify succinctly.  Furthermore, I don't think that's a
core concern which needs to be spelled out in the formal Release Policy.  To
my mind that's an Infrastructure issue, along with such details as
bandwidth/file-size limitations, gory details of uploading, technical
requirements for cryptographic sigs, and so on.

The draft contains the following TODO section, broaching the idea of
a formalized "Release Distribution Policy" where such rules could live:

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

Naturally I would not assume that approval for the rest of the draft
constitutes a mandate to implement these TODO items.

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

Excellent.  Thanks for the feedback!

Marvin Humphrey

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

View raw message