www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Release Policy
Date Fri, 23 May 2014 18:33:29 GMT
Yes it is as JJ says as long as a vote happens the tools matter not. Though
why the vote has to happen is yet to be clarified other than meandering
justifications.
On May 23, 2014 11:56 AM, "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