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/...

[John Baldwin]

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.

-- 
John Baldwin