www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: Release Policy
Date Fri, 23 May 2014 17:34:57 GMT
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 <aharui@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> 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" <sebbaz@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
>
>
>
Mime
View raw message