Return-Path: X-Original-To: apmail-legal-discuss-archive@www.apache.org Delivered-To: apmail-legal-discuss-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5A5181171B for ; Fri, 23 May 2014 21:26:21 +0000 (UTC) Received: (qmail 45682 invoked by uid 500); 23 May 2014 21:26:21 -0000 Delivered-To: apmail-legal-discuss-archive@apache.org Received: (qmail 45517 invoked by uid 500); 23 May 2014 21:26:21 -0000 Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: Reply-To: legal-discuss@apache.org List-Id: Delivered-To: mailing list legal-discuss@apache.org Received: (qmail 45508 invoked by uid 99); 23 May 2014 21:26:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 May 2014 21:26:21 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of brian.leroux@gmail.com designates 209.85.223.178 as permitted sender) Received: from [209.85.223.178] (HELO mail-ie0-f178.google.com) (209.85.223.178) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 May 2014 21:26:17 +0000 Received: by mail-ie0-f178.google.com with SMTP id rl12so5429518iec.23 for ; Fri, 23 May 2014 14:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=UttQrj6JRqpnaplZlN+JxSoVk5nAGF16LKLO0pmMKFo=; b=ZzHXDhPsmx2j1+JJlszJEEVFC0ybtm/ZYEMaJO/pgEA2TMHQEwXW+8W9E15Ar/MQJB /Yc5zHlJxaCYoUBK0LHaf8ACSS0A2+jySc37tX+FsdPYvRJo9LaXn0OeAk2h+GT5gawu 1OmcB5dr1Q1aukD/jrVA0JIsa2QiNlHwtfr0OX28i5lE6offVYA0K8uTf4xllQB+T+uk mOW5pbm1dQvFrvUIooLITfZQxkXxCEh4/56a77Ffe4tqDbIyOVCzP8fcgTVHwM6Fc4Cp mQ2O1H29oEMtJyHDzA/1tyNBOmy+BGbpaBurbwg+97Dq/1cjKCi83EUv8H8tQWeE9Xuu UNMA== MIME-Version: 1.0 X-Received: by 10.50.80.10 with SMTP id n10mr7837424igx.40.1400880353440; Fri, 23 May 2014 14:25:53 -0700 (PDT) Sender: brian.leroux@gmail.com Received: by 10.50.173.40 with HTTP; Fri, 23 May 2014 14:25:53 -0700 (PDT) In-Reply-To: References: <1400784905.88428.YahooMailNeo@web28903.mail.ir2.yahoo.com> <1400790465.3527.YahooMailNeo@web28902.mail.ir2.yahoo.com> <537E5ED4.4010209@apache.org> <1400792669.96132.YahooMailNeo@web28902.mail.ir2.yahoo.com> <1400820943.12576.YahooMailNeo@web28901.mail.ir2.yahoo.com> <2C3CDF92-FD51-4932-8A1F-69188FEC2F4B@jaguNET.com> Date: Fri, 23 May 2014 16:25:53 -0500 X-Google-Sender-Auth: IKJP-gp0pJvb22JXdmsRI30wnas Message-ID: Subject: Re: Release Policy From: Brian LeRoux To: legal discuss Content-Type: multipart/alternative; boundary=089e0149391ed6fa3004fa17dffe X-Virus-Checked: Checked by ClamAV on apache.org --089e0149391ed6fa3004fa17dffe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable IMO, we did not have release difficulties until Sebb and the board to inform us we were doing it wrong. Shipping was something we were proud to have a bias for as it is fairly proven at this point in our industry to be the main reason projects fail. Going from releasing often to having emails about whether we're going to ship or not is not sending a positive message to the community! Anyhow. =3D/ Since then, December I think, we've been revamping our release tooling to support the policy amidst time lost arguing about how to best do that. We can't turn back time but we certainly can help avoid this happening again and mitigate the very real perception issues you outline below. On Fri, May 23, 2014 at 4:02 PM, Dave Cottlehuber wrote= : > > On May 23, 2014 11:47 AM, "Jim Jagielski" 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? > > > > Also my case however I=E2=80=99ve followed the mailing lists & the curren= t updated > http://www.apache.org/dev/release.html and > http://www.apache.org/dev/release-publishing cover the requirements & > reasoning for me clearly. > > Joe, Brian - is there anything in the 2 links above that isn=E2=80=99t > sufficiently clear, that you=E2=80=99d need improved? > > BTW prior to the earlier discussions on this list, I also wasn=E2=80=99t = aware of > the reasoning behind the ASF release processes, at least the mandated > components, e.g. ensuring appropriate licencing for all included > components. Obvious in hindsight. For CouchDB we have had, for a long tim= e, > an automated check in `make distcheck` that ensures only files with an AL= v2 > header can come through, or a committer needs to add an exclusion, not > unlike updating svn/gitignore. This helps a lot. > > > Not that I want to ever see you personally given how miserable you are > over e-mail. > > Unnecessary. > > > > > On May 23, 2014 11:56 AM, "Alex Harui" wrote: > > > > This current proposal no longer requires 72 hour voting. To me, thi= s > > > > means that we could eventually automate releasing to the point wher= e > 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? > > From my limited ASF experience, I=E2=80=99d guess that this meets the Fou= ndation=E2=80=99s > requirements (viz the earlier URLs) and if your community=E2=80=99s OK wi= th it why > not. 72 hours IIRC is not mandated, its a guideline across many projects > based on striking a balance between full consensus and fast releases. > > > > > What if a machine did the downloading of packages, signature > verification, > > > > RAT, SCM compare and build so the voters only need to review a repo= rt > > > > before voting. Would that also meet requirements and be acceptable? > > > > > Thanks, > > > > -Alex > > I have a personal script that does most of this for me for CouchDB, and > assuming you=E2=80=99re on top of the commits coming through anyway, it s= eems > =E2=80=9Csufficient to meet criteria=E2=80=9D. If everybody contributed t= o that script for > a given project it could be a very comprehensive check. > > However the bigger picture here is that the Foundation partly exists to > provide a legal cushion for projects & their representatives. We have a > number of ASF people who have experience of the need for that cushion, an= d > as somebody who used to work for Telcos and Big Tech, I fully understand > the need for that cushion. > > I=E2=80=99m reluctant to pull all the feathers out of the cushion, only t= o find > later that a crack-smoking team of opposing lawyers just pwned my house a= nd > put my family on the street. It=E2=80=99s speculation to say that removin= g all but > the final Rubber Stamp +1 (I read the report, its sweet bro) is > *definitely* legally sustainable in the face of determined opposition fro= m > for example Patent Trolls. The potentially increased risk is simply not > quantifiable, esp IANAL etc. > > Finally, for the =E2=80=9Colder ASFers=E2=80=9D here. I get your concerns= , and I=E2=80=99ve had > enough big corp business experience to understand the continued need to > keep that risk managed. > > However I suspect that a large part of Cordova peoples=E2=80=99 concerns = (and > others) is that there is a foaming, cresting, evolving wave of open sourc= e > out there, where hundreds of thousands of people surf and live on the > bleeding edge of packages, across javascript, haskell, erlang, clojure an= d > others, who are not afraid of a few incompatibilities along the way. Thos= e > people pushing the limits of what they can do are ones we should bring, a= nd > keep, on board. > > We need to ensure that the ASF retains its pride of place for Superb > Software, in this new mad crazy world, without compromising its principle= s. > Whether this means refining and evolving the acceptable level of > automation, continuing the vastly improved release process documentation, > or something else, make no mistake =E2=80=94 the single biggest risk to t= he > Foundation=E2=80=99s long term existence is to be labelled a dinosaur =E2= =80=94 whether > unfairly or not. > > Brian, Joe, Alex, if you got this far, are you implying that a/the reason > for the drop in release cadence for Cordova was as a result of release > process difficulties? What can we do to help your project? Anything else? > > A+ > dch > -- > Sent from my Couch > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org > For additional commands, e-mail: legal-discuss-help@apache.org > > --089e0149391ed6fa3004fa17dffe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IMO, we did not have release difficulties until Sebb and t= he board to inform us we were doing it wrong. Shipping was something we wer= e proud to have a bias for as it is fairly proven at this point in our indu= stry to be the main reason projects fail. Going from releasing often to hav= ing emails about whether we're going to ship or not is not sending a po= sitive message to the community! Anyhow. =3D/

Since then, December I think, we've been revamping our release tool= ing to support the policy amidst time lost arguing about how to best do tha= t. We can't turn back time but we certainly can help avoid this happeni= ng again and mitigate the very real perception issues you outline below.


On Fri, May 2= 3, 2014 at 4:02 PM, Dave Cottlehuber <dch@jsonified.com> wro= te:
=C2=A0> On May 23, 2014 11:47 AM, &q= uot;Jim Jagielski" 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?
>

Also my case however I=E2=80=99ve followed the mailing lists & th= e current updated http://www.apache.org/dev/release.html and http://www.apach= e.org/dev/release-publishing cover the requirements & reasoning for= me clearly.

Joe, Brian - is there anything in the 2 links above that isn=E2=80=99t suff= iciently clear, that you=E2=80=99d need improved?

BTW prior to the earlier discussions on this list, I also wasn=E2=80=99t aw= are of the reasoning behind the ASF release processes, at least the mandate= d components, e.g. ensuring appropriate licencing for all included componen= ts. Obvious in hindsight. For CouchDB we have had, for a long time, an auto= mated check in `make distcheck` that ensures only files with an ALv2 header= can come through, or a committer needs to add an exclusion, not unlike upd= ating svn/gitignore. This helps a lot.

> Not that I want to ever see you personally given how miserable you are= over e-mail.

Unnecessary.

> > > On May 23, 2014 11:56 AM, "Alex Harui" wrote:
> > > This current proposal no longer requires 72 hour voting. To = me, this
> > > means that we could eventually automate releasing to the poi= nt where the
> > > CI prepares a set of packages with MD5 sums separately prepa= res a report
> > > of all new files and all files with changes to the headers.<= br> > > >
> > > The RM then runs another tool that downloads the packages, v= erifies the
> > > MD5, signs with the PGP key (yes, the RM has to type in thei= r password)
> > > and uploads it to the RC server.
> > >
> > > Then three folks run another tool that downloads the package= s, 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?

From my limited ASF experience, I=E2=80=99d guess that this meets the= Foundation=E2=80=99s requirements (viz the earlier URLs) and if your commu= nity=E2=80=99s OK with it why not. 72 hours IIRC is not mandated, its a gui= deline across many projects based on striking a balance between full consen= sus and fast releases.

> > > 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 acce= ptable?

> > > Thanks,
> > > -Alex

I have a personal script that does most of this for me for CouchDB, a= nd assuming you=E2=80=99re on top of the commits coming through anyway, it = seems =E2=80=9Csufficient to meet criteria=E2=80=9D. If everybody contribut= ed to that script for a given project it could be a very comprehensive chec= k.

However the bigger picture here is that the Foundation partly exists to pro= vide a legal cushion for projects & their representatives. We have a nu= mber of ASF people who have experience of the need for that cushion, and as= somebody who used to work for Telcos and Big Tech, I fully understand the = need for that cushion.

I=E2=80=99m reluctant to pull all the feathers out of the cushion, only to = find later that a crack-smoking team of opposing lawyers just pwned my hous= e and put my family on the street. It=E2=80=99s speculation to say that rem= oving all but the final Rubber Stamp +1 (I read the report, its sweet bro) = is *definitely* legally sustainable in the face of determined opposition fr= om for example Patent Trolls. The potentially increased risk is simply not = quantifiable, esp IANAL etc.

Finally, for the =E2=80=9Colder ASFers=E2=80=9D here. I get your concerns, = and I=E2=80=99ve had enough big corp business experience to understand the = continued need to keep that risk managed.

However I suspect that a large part of Cordova peoples=E2=80=99 concerns (a= nd others) is that there is a foaming, cresting, evolving wave of open sour= ce out there, where hundreds of thousands of people surf and live on the bl= eeding edge of packages, across javascript, haskell, erlang, clojure and ot= hers, who are not afraid of a few incompatibilities along the way. Those pe= ople pushing the limits of what they can do are ones we should bring, and k= eep, on board.

We need to ensure that the ASF retains its pride of place for Superb Softwa= re, in this new mad crazy world, without compromising its principles. Wheth= er this means refining and evolving the acceptable level of automation, con= tinuing the vastly improved release process documentation, or something els= e, make no mistake =E2=80=94 the single biggest risk to the Foundation=E2= =80=99s long term existence is to be labelled a dinosaur =E2=80=94 whether = unfairly or not.

Brian, Joe, Alex, if you got this far, are you implying that a/the reason f= or the drop in release cadence for Cordova was as a result of release proce= ss difficulties? What can we do to help your project? Anything else?

A+
dch
--
Sent from my Couch



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


--089e0149391ed6fa3004fa17dffe--