www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Finishing release policy codification
Date Tue, 25 Aug 2015 08:58:45 GMT
On 25 August 2015 at 02:38, Marvin Humphrey <marvin@rectangular.com> wrote:
> 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 mentioned bug submitters because they are a particularly common case
where snapshots are useful, not just to try and find all possible use cases.
I don't think they are a corner case.

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

Sorry, but I don't find the use of the word "approximated" obvious in meaning.
For example:
A dev list is a mailing list, and so is the user list.
Whereas the bug tracker is not a mailing list
Which is more closer (more approximate) to the dev list?

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

"the dev list(s)" would be better.

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

I don't read it that way. The last sentence only appears to grant
permission to mention
snapshots to the set of people reading dev lists or archives. i.e.
it's clearly OK to provide
such links in postings on the dev list, but other references appear to
be excluded.

> 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

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

View raw message