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

Re: [Xen-devel] Cut-off date for Xen 4.11 is March 30th, 2018



On Thu, Mar 29, 2018 at 04:35:27AM -0600, Jan Beulich wrote:
> >>> On 29.03.18 at 12:22, <george.dunlap@xxxxxxxxxx> wrote:
> > On 03/29/2018 10:56 AM, Juergen Gross wrote:
> >> On 29/03/18 11:53, George Dunlap wrote:
> >>> On 03/29/2018 07:52 AM, Juergen Gross wrote:
> >>>> Hi all,
> >>>>
> >>>> The cut-off date for Xen 4.11 is March 30th, 2018. If you want your
> >>>> features to be included for the release, please make sure they are
> >>>> committed by March 30th, 2018.
> >>>
> >>> March 30th is a public holiday here in the UK.  Is it the same in
> >>> Germany?  Would it be OK to say that things sent on Friday can be
> >>> committed on Tuesday 3 April if the appropriate maintainer wasn't around
> >>> to review them?
> >>>
> >>> If not we should warn people to get their stuff reviewed today if at all
> >>> possible.
> >>>
> >>> As it happens I'll be working Friday so I can check in stuff that's got
> >>> the right Acks / R-b's; but I won't do last-pass reviews on behalf of
> >>> maintainers.
> >> 
> >> I already thought of shifting the freeze by one week. Main reason is
> >> that several maintainers seem to have a backlog of patches to review
> >> which IMO should make it into 4.11.
> >> 
> >> Thoughts?
> > 
> > Well there's a benefit to this, but also a risk: that people will begin
> > to see the "hard freeze" as more like a "soft freeze", that will always
> > be pushed back / flexed if you push hard enough.  Part of the purpose of
> > setting the hard freeze months in advance is so that people can plan
> > ahead and get stuff reviewed in time; part of the reason for having
> > 6-month releases is so that the cost of delaying a feature / patchset to
> > the next release isn't very high.
> 
> As mentioned before I think anyway that we should revisit this
> hard freeze date approach. I would much favor a hard freeze
> date on where it is determined which features are intended to
> make it and which not. Right now at least everything related to
> Spectre and Meltdown would imo want to go into the category
> of "we'll wait until it's in".
> 

You're mixing up two things: features and security fixes (and their
subsequent patches). I agree the latter should get special attention
because missing those would essentially render a release useless or
unattractive.  Meltdown and Spectre fall into the second category, as
with all the XSAs.

But most of the time, and most developers / contributors write new
features.  If they are identified with strategic importance, we should
wait (livepatching comes to mind), but for normal ones (which noone
argues for), we should have the default position to not wait.

This isn't incompatible with what you said.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.