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 19:23:12 GMT
How nice.

On May 23, 2014, at 3:14 PM, Joe Bowser <bowserj@gmail.com> wrote:

> 
> On May 23, 2014 11:47 AM, "Jim Jagielski" <jim@jagunet.com> wrote:
> >
> > This was discussed, at length, both on various mailing
> > lists as well as at the f2f rountable @ ApacheCon.
> >
> 
> You are aware that people on this list didn't attend ApacheCon for either personal or
professional reasons? Not that I want to ever see you personally given how miserable you are
over e-mail.
> 
> > I am sorry if such clarification isn't enough for you,
> > but, at the end of the day, that's your issue, not mine.
> > You may disagree with it, and you are welcome to do so,
> > but to claim that the justifications have been "meandering"
> > is both inaccurate and self-serving.
> >
> > On May 23, 2014, at 2:33 PM, Brian LeRoux <b@brian.io> wrote:
> >
> > > 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
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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