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

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’ve followed the mailing lists & the current updated and cover the requirements & reasoning for me clearly.

Joe, Brian - is there anything in the 2 links above that isn’t sufficiently clear, that you’d need improved?

BTW prior to the earlier discussions on this list, I also wasn’t 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 time, an automated 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 updating svn/gitignore. This helps a lot.

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


> > > 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 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?

From my limited ASF experience, I’d guess that this meets the Foundation’s requirements (viz the earlier URLs) and if your community’s OK with 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 report
> > > 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’re on top of the commits coming through anyway, it seems “sufficient to meet criteria”. If everybody contributed to 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, and as somebody who used to work for Telcos and Big Tech, I fully understand the need for that cushion.

I’m 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 house and put my family on the street. It’s speculation to say that removing all but the final Rubber Stamp +1 (I read the report, its sweet bro) is *definitely* legally sustainable in the face of determined opposition from for example Patent Trolls. The potentially increased risk is simply not quantifiable, esp IANAL etc.

Finally, for the “older ASFers” here. I get your concerns, and I’ve 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’ concerns (and others) is that there is a foaming, cresting, evolving wave of open source out there, where hundreds of thousands of people surf and live on the bleeding edge of packages, across javascript, haskell, erlang, clojure and others, who are not afraid of a few incompatibilities along the way. Those people pushing the limits of what they can do are ones we should bring, and 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 principles. Whether this means refining and evolving the acceptable level of automation, continuing the vastly improved release process documentation, or something else, make no mistake — the single biggest risk to the Foundation’s long term existence is to be labelled a dinosaur — 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?

Sent from my Couch

To unsubscribe, e-mail:
For additional commands, e-mail: