www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <...@jsonified.com>
Subject Re: Release Policy
Date Fri, 23 May 2014 21:02:58 GMT
 > 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 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’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.

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

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


Mime
View raw message