www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Release Policy
Date Fri, 23 May 2014 19:14:02 GMT
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
>

Mime
View raw message