www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Bundling and LICENSE
Date Sun, 03 Apr 2016 14:29:58 GMT

On 4/3/16, 4:13 AM, "Mark Thomas" <markt@apache.org> wrote:
>> I guess the related question is how much we should trust the upstream
>> community's L&N.  Are we required to do what is the equivalent of an IP
>> clearance for third-party bundles in our binary releases for every
>> release?  Or can we trust the top-level L&N we find in the upstream
>> packages?  Otherwise, it seems to really raise the bar on release
>> reviewing.  In the extreme, you shouldn't even trust upstream ASF
>> releases as the upstream PMC may have made a mistake in their release.
>>  I remember back in incubation days where our mentors only reviewed the
>> source package.  Nowadays, a Flex release review seems to require
>> checking L&N in the binary, the L&N in the doc package, the L&N in every
>> JAR in the binary, and now potentially, every file in every third-party
>> bundle in the binary.  Were we supposed to be doing this all this time?
>>  And must any L&N issue found in third-party bundles be a release
>> blocker lest the PMC be accused of not upholding the ASF policies on
>> correct L&N?
>You trust that upstream is correct but if you find something that looks
>odd - or are made aware of something that looks odd - then you have to
>get to the bottom of it. (And ideally encourage all involved to improve
>docs etc. so the next person to find the oddity also finds the

Makes sense, but I've been wondering whether the "have to" part is
responsible for low and slow voter turnout and an inability to recruit new
release managers in our community.  As soon as one PMC member is willing
to not trust the top-level docs from an upstream dependency, then really,
that person can void every other PMC member's vote because as soon as an
irregularity is found, the RM and other PMC members are essentially
obligated to cancel that RC and wait until the investigation is complete.
Otherwise, the RM and PMC members could be accused of being derelict in
their duty to uphold the Legal Affairs Policy of the ASF.  So why should
any PMC member bother to examine the release until the PMC members who
don't trust top-level docs have done their reviews?  And if those PMC
members are busy, then the entire release process must wait for them,
because otherwise you may think you are all set but at the 71st hour, some
detail is found.  While code quality bugs are subjective and I suppose are
the reason for the theory that you can't veto a release, a policy
violation is essentially a veto.  No PMC member should try to overlook one.

Or else, every PMC member must raise their review effort to try to match
the PMC members who have the time and motivation to not trust the
top-level docs of the upstream dependencies, but I think many of our PMC
members don't have the time.  How does it work in your community?  What is
the average amount of time spent reviewing releases?  Do folks just run
RAT on the source package, eye-ball the L&N and vote?

We also rarely get non-binding votes on our releases.  The 'feel' of the
release process isn't so much "hey, try this out and see if the code
works", it is a call for volunteers to grind through each file looking for
policy violations.  IMO, it would be interesting to see if we would get
more release participation if PMC members could not be accused of being
derelict in their duty if issues are found in third-party convenience
binary bundles.  Anything found there could be fixed in the next release,
or whenever the upstream community reaches their own conclusion on how to
adjust the top-level docs.  Or is the ASF liable and/or would our
reputation suffer if issues in upstream bundles are found in binary
packages on our dist server?

I keep wishing ASF participation was more of the "potluck" that Roy
described to me once.  These days if feels like we have to be food
inspectors on everyone's dishes.


View raw message