www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Release Policy
Date Fri, 23 May 2014 15:43:09 GMT
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


Mime
View raw message