svn commit: r269847 - in stable/10: contrib/apr contrib/apr/docs contrib/apr/encoding contrib/apr/file_io/unix contrib/apr/include contrib/apr/include/arch/unix contrib/apr/include/private contrib/...
jhb at freebsd.org
Thu Aug 14 16:07:15 UTC 2014
On Tuesday, August 12, 2014 4:23:16 pm Peter Wemm wrote:
> On Tuesday 12 August 2014 11:19:31 John Baldwin wrote:
> > On Monday, August 11, 2014 9:40:12 pm Peter Wemm wrote:
> > > Author: peter
> > > Date: Tue Aug 12 01:40:11 2014
> > > New Revision: 269847
> > > URL: http://svnweb.freebsd.org/changeset/base/269847
> > >
> > > Log:
> > > MFC r266728,266731,266735,266736,268135,268960,269833
> > >
> > > Update apr 1.4.8 -> 1.5.1
> > > Update apr-util 1.5.2 -> 1.5.3
> > > Update serf 1.3.4 -> 1.3.7
> > > Update svnlite 1.8.8 -> 1.8.10
> > > Deal with svnlite.1 manpage.
> > Isn't this merge a little quick? 1.8.10 only went into head about 6 hours
> > before this commit. The 1.8.8 merge to 10 was also rather quick (less than
> > an hour after it was merged to HEAD). If the security issues noted in the
> > commit for HEAD are severe enough to warrant an immediate merge, then there
> > should probably be an advisory. Otherwise, I think svn updates should
> > probably have some bake time in HEAD before going to stable.
> The jumbo-MFC was mostly to gather up the updates that have been baking in
> head for a while. 10.1 is coming up soon.
> It just seemed silly to MFC everything except a specific, targeted security fix.
> I suspect that for every question I got about including the security update,
> I'd have received 5 times as many asking why I hadn't included it.
Surely the MFC could have waited 3 days or so though? We generally default to
having some sort of bake-in period for MFCs and only bypassing that if there is
an urgent need (such as an SA). The code flush for 10.1 is still a week away.
More information about the svn-src-all