Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Subject: Re: Release Policy
From: Jim Jagielski <jim@jaguNET.com>
In-Reply-To: 
 <CAOBL_k7RnmWLuZCR1jqNMiR6nCJHneqj23sUxtcHhwa-Yzpczg@mail.gmail.com>
Date: Fri, 23 May 2014 15:23:12 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <965E0CDD-728F-494A-AECB-518F60BE0E66@jaguNET.com>
References: 
 <CAAS6=7jTVyaDhwepAqob-=83DxJ-uaMS9GyG5j5XdHYybvAtGQ@mail.gmail.com>
 <1400784905.88428.YahooMailNeo@web28903.mail.ir2.yahoo.com>
 <CAAS6=7iGt0xW4oBe0sSXC7RzGgDP=KUBhgkOjzUezBbirq2sJA@mail.gmail.com>
 <1400790465.3527.YahooMailNeo@web28902.mail.ir2.yahoo.com>
 <537E5ED4.4010209@apache.org>
 <1400792669.96132.YahooMailNeo@web28902.mail.ir2.yahoo.com>
 <CADVgkyO09rhuYkRUtBfCavJYMRxKneP8E_Hi5_LsOEdfpTWRtw@mail.gmail.com>
 <1400820943.12576.YahooMailNeo@web28901.mail.ir2.yahoo.com>
 <CADVgkyOevfr_6v+MNtKmrb+ajRAjJcAAbVvJXGJ+6Az07hiT3g@mail.gmail.com>
 <CAOGo0VY+b8QJZtWGhhUo1jodqZ2ewfBSbGXx4xyt8QueeTsRUQ@mail.gmail.com>
 <CADVgkyOpTj9L899uM5jHJm41GM997y_K=Qjd9+JDmvzcYQQiGg@mail.gmail.com>
 <D3788CC0-C204-4D6B-94EE-89FA342535F8@jaguNET.com>
 <CFA4C86F.22818%aharui@adobe.com>
 <CADVgkyMHgg7hOBZoFXdt7bWAfhR8iwNpQneYmmj-AXcP1uXvjg@mail.gmail.com>
 <2C3CDF92-FD51-4932-8A1F-69188FEC2F4B@jaguNET.com>
 <CAOBL_k7RnmWLuZCR1jqNMiR6nCJHneqj23sUxtcHhwa-Yzpczg@mail.gmail.com>
To: legal-discuss@apache.org

How nice.

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

>=20
> 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.
> >
>=20
> 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.
>=20
> > 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