[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 6.0.7 planning



On Sun, Feb 17, 2013 at 11:12:18PM +0000, Ben Hutchings wrote:
> On Sun, 2013-02-17 at 13:33 -0800, dann frazier wrote:
> > On Sun, Feb 17, 2013 at 03:14:04PM +0000, Adam D. Barratt wrote:
> > > On Fri, 2013-02-15 at 11:32 +0000, Adam D. Barratt wrote:
> > > > On Fri, 2013-02-15 at 01:41 +0000, Ben Hutchings wrote:
> > > > > On Thu, 2013-02-14 at 10:28 -0800, dann frazier wrote:
> > > > > > Security update has been uploaded. I'll post the builds somewhere as
> > > > > > they become available for anyone interested in testing.
> > > > > 
> > > > > Version 2.6.32-48 has also been uploaded.
> > > > 
> > > > Flagged for acceptance; thanks.
> > > 
> > > All the builds are now in, so we should be ready for lkdi updates when
> > > convenient.
> > > 
> > > I gather there's a chance there might need to be further security
> > > updates; will that mean we need another update in p-u?
> > 
> > Possibly; an alternative would be to release a 48squeeze1 via security
> > to sync up w/ the fixes just before the point release. That would let
> > us go ahead and get the lkdi/d-i updates ready and give us some
> > flexibility to react to any follow-on changes that may appear this
> > week as CVE-2013-0871 is discussed. On the other hand, I know Ben has
> > another fix queued for stable, and I saw a mention of a possible
> > s390/KVM regression - so those may justify the extra p-u update.
> >
> > Thoughts?
> 
> I would prefer to give users the option to install just the urgent
> security fixes and delay upgrading to the point release.  Releasing a
> 48squeeze1 means bundling together all those changes.

Agreed; and I think I was unclear. I was taking for granted that we
*will* do a 46squeeze2 now w/ the CVE-2013-0871 fix and bypass
46squeeze1. 46squeeze2 would provide the security-only option.

The question was whether or not we should try and fix p-u by getting a
-49 into -stable now w/ the CVE-2013-0871 fix, or just make sure
there's a 48squeeze1 in security for after. Ah - but maybe the point
you're making is that a 48squeeze1 in security would make 46squeeze2
harder to find/install - if so, I can understand that point.

> I don't think it's critical that the installer has the same kernel
> version as the stable suite.  We do need to be careful with ordering of
> the changelog to allow the installer kernel version to be constructed
> from the later version by running debian/bin/patch.apply, and/or ask the
> FTP team nicely to ensure the older version remains in squeeze.

Ordering it properly shouldn't be a problem.


Reply to: