www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: Finishing release policy codification
Date Tue, 25 Aug 2015 01:38:53 GMT
On Sun, Aug 23, 2015 at 3:12 PM, sebb <sebbaz@gmail.com> wrote:
> On 23 August 2015 at 03:59, Marvin Humphrey <marvin@rectangular.com> wrote:
>> On Sat, Aug 22, 2015 at 3:36 AM, sebb <sebbaz@gmail.com> wrote:
>>> The phrase is now:
>>> "... MUST only add binary/bytecode files that are the result of compiling
>>> that version of the source code release and its dependencies."
>>>
>>> This could mean either that the RM compiled the dependency from source,
>>> or they included a pre-compiled version of the dependency.
>>> Are both meanings intentional?
>>
>> Yes.  My understanding of current policy is that when assembling
>> "convenience binaries", including pre-compiled versions of dependencies is
>> permitted.
>
> This is what I understood as well.
>
>> Consider that the alternative -- requiring that all dependencies must be
>> compiled locally -- yields marginal benefit at substantial cost.
>> Security-conscious consumers will shun convenience binaries as potential
>> trojan horses regardless, as they are produced on uncontrolled RM developer
>> machines.
>
> Agreed.
>
> I suspect some people may read the phrase and think it means only one or the
> other.  It would be helpful to clarify the intent to avoid future arguments.

Hmm, let's see.  There hasn't really been a lot of confusion up till now, even
though the current language is *less* accurate.  In my view this passage is
now adequately clear.

Thanks to this thread, the intent of the drafters is now captured in the
public archives of this mailing list, so arguments should be settled quickly.
Furthermore, the failure mode of misinterpreting that passage is inconvenience
to the RM, which might be unfortunate but is not as serious as a bad release.

>>> The policy appears to disallow *any* mention of snapshot builds on the
>>> website.
>>
>> That is certainly not the intent.  Do the two last commits on this branch
>> address your concern?
>>
>>     https://github.com/rectang/asfrelease/commits/unreleased_dist_v1
>
> Sorry, not really.
>
> The definition of developer does not appear to include people who submit bug
> reports.

Bug submitters are a corner case.  The development community is still
essentially the "people following the dev list (or searching its archives)".

I think it was a win to add "approximated" in order to cover the corner case
of bug submitters along with a bunch of others.  But it would be silly to
attempt enumeration of all possible corner cases.  (Security researchers?
Infra?)

> Note also that there may be several dev lists (dev, commits,
> issues), and the phrase "a product dev list" could be taken to mean a dev
> list from a different product (which might not even be an ASF one)

OK, I will keep "approximated" but modify that commit to stick with "the dev
list" instead of changing to "a dev list".

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

Hmm.  I'm not seeing that.  Here's the complete section after the revisions:

    ## 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 direct outsiders towards official releases
    rather than raw source repositories, nightly builds, snapshots, release
    candidates, or any other similar packages.** The only people who are
    supposed to know about such developer resources are the people following
    the dev list (or searching its archives) and thus aware of the conditions
    placed on unreleased materials.

That language should make it possible to "direct outsiders toward official
releases" on the main download page while simultaneously directing members of
the dev community towards snapshots (or similar) via dev-centic web pages or
other dev-centric communication channels.

By the way, I'm glad we focused on this passage.  I was somewhat dissatisfied
with the previous language, but didn't want to burden reviewers with
additional changes.

>>> However historically this has been done on website pages which are
>>> solely directed at the development community.
>>
>> Indeed.
>>
>> The current release policy page has quite a lot to say on the
>> subject[1][2][3][4][5].  But it is not complicated, merely repetitive and
>> insistent.  The policy boils down to this:
>>
>> *   A "developer community" is approximated for the purpose of release policy
>>     as "people following the dev list (or searching its archives)"
>> *   Unreleased materials, in any form, may only be shared within the developer
>>     community.
>>
>> That is the only interpretation which is consistent with all passages in the
>> current release policy page.
>
> I'm not sure I agree that the policy disallows links on developer web pages
> See below.

There seems to have been a miscommunication.  It is not my belief that policy
disallows links to snapshots on dev-centric pages.

>>     - **Nightly Builds** are simply built from the Subversion trunk,
>
> [That needs to change as we also use Git; and some projects may build
> from branches]

That's an issue, but since it's in the "Release FAQ" section which is an exact
reproduction of the current release policy, let's file it away for future
reference.

Once the current policy text is demoted to a supporting role as "Release FAQ",
it will need to be edited for clarity and economy.  However, it is asking too
much for people to review *both* the new codified Release Policy and an FAQ at
the same time.  I expect instead to submit incremental revisions to the FAQ
later.

Marvin Humphrey

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


Mime
View raw message