On Thu, 23 Apr 2015, Dan Fandrich wrote:

> 1) A total freeze for 24h before the release to wait for a successful run of
> autobuilds. This isn't ideal when the release includes security fixes, but
> this isn't the first time that a last-minute security patch has caused big
> build breakages.

Yeah. I can't recall exactly why it happened the last few times (it was a few
years ago) but this time it was clearly the last-minute security patch
problem. I think we have reasons to believe that we will have more of that
sort in the future too (last-minute security patches I mean).

If there would be such a freeze, would we do the security announcements first
then wait or would we just commit the security stuff and have it in the repo
unannounced for those 24 hours? Neither way feels very good. :-/

My take away is also to run more tests and builds of my own on the security
patches I have pending.

> 2) Extending the feature freeze until 48h after a release is made to make a
> re-release easier.

We can also get used to branch off to do follow-up releases...

> 3) Convince someone to run an autobuild from the daily tarball instead of
> git. I used to do this for all my autobuilds (and it caught a number of
> problems of files from the tar balls) but switched to git when switching to
> a new build machine.

Yeah, it would be very useful. And a set of different builds from tarballs
too... But this comes down to the good old problem with resources and
volunteers etc. A good idea but hard to make happen.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html