www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Release Policy
Date Fri, 23 May 2014 21:25:53 GMT
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 <dch@jsonified.com> 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
> 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