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:39:13 GMT
You're right... I'm not aware of much. In fact, I don't
know that much either... I don't know much about history,
don't know much biology; I don't know much about a science book
and don't know much about the French I took.

But I do know that I love you. And I know that if you love me, too,
what a wonderful world this would be.

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

> Just checking if you were aware, since you don't seem to be aware of much.
> 
> On May 23, 2014 12:23 PM, "Jim Jagielski" <jim@jagunet.com> wrote:
> 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
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message