> On May 23, 2014 11:47 AM, "Jim Jagielski" wrote:Also my case however I’ve followed the mailing lists & the current updated http://www.apache.org/dev/release.html and http://www.apache.org/dev/release-publishing cover the requirements & reasoning for me clearly.
> > 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?
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.
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.
> > > 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?
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.
> > > 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
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.
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