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: Release Policy
Date Fri, 23 May 2014 20:19:30 GMT


On 5/23/14 12:31 PM, "Mark Thomas" <markt@apache.org> wrote:
>One thing that has just occurred to me that I think would make a big
>difference is if a "release" CI system built the binaries from a source
>tarball rather than directly from version control. Doing this removes
>all the "How do you prove what the CI system built is the same as would
>be built from the source tarball?" issues.
>
>Thoughts?
Exactly.  My proposal is that voters review output from a different
automation process that validates the source package.  I already use an
ant script to do that when voting.  It makes sure I don't skip steps. It
hoists editor windows in my face with LICENSE and NOTICE and the rat
report.
>
>(I don't think this helps with the 72-hour window though.)
IMO, we trust RMs and PMCs enough already that we could trust them with
subjectivity in how long the vote lasts.  If the project gets complaints
that the window isn't long enough, the RM will likely respond
appropriately.  The ultimate goal is how to best serve the community.  For
RC1 of the mainstream Flex package, I would always wait at least 24 hours
and want to see votes from different geographies, even if I got 3 US votes
in the first 15 minutes.  For RCn, after we've hopefully vetted the major
issues and are just tweaking RELEASE_NOTES, why wait 72 hours?

>
>Mark
>
>> 
>> -Alex
>> 
>> From: Brian LeRoux <b@brian.io <mailto:b@brian.io>>
>> Reply-To: "legal-discuss@apache.org <mailto:legal-discuss@apache.org>"
>> <legal-discuss@apache.org <mailto:legal-discuss@apache.org>>
>> Date: Friday, May 23, 2014 11:33 AM
>> To: legal discuss <legal-discuss@apache.org
>> <mailto:legal-discuss@apache.org>>
>> Subject: Re: Release Policy
>> 
>> 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
>> <mailto: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
>>     <mailto: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
>><mailto:b@brian.io>> wrote:
>>     >
>>     >> C'mon Sebb. This is circular false logic.
>>     >>
>>     >> On May 23, 2014 10:29 AM, "sebb" <sebbaz@gmail.com
>><mailto:sebbaz@gmail.com>> wrote:
>>     >> On 23 May 2014 16:01, Brian LeRoux <b@brian.io
>><mailto: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 <mailto: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
>><mailto: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
>>     <mailto:legal-discuss-unsubscribe@apache.org>
>>     >> For additional commands, e-mail: legal-discuss-help@apache.org
>><mailto:legal-discuss-help@apache.org>
>>     >>
>>     >
>>     >
>>     
>>>---------------------------------------------------------------------
>>     >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>     <mailto:legal-discuss-unsubscribe@apache.org>
>>     >For additional commands, e-mail: legal-discuss-help@apache.org
>><mailto:legal-discuss-help@apache.org>
>>     >
>> 
>> 
>>     
>>---------------------------------------------------------------------
>>     To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>     <mailto:legal-discuss-unsubscribe@apache.org>
>>     For additional commands, e-mail: legal-discuss-help@apache.org
>>     <mailto: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