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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.03.18 at 12:50, <wei.liu2@xxxxxxxxxx> wrote:
> 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.

Subsequent patches to security fixes, unless they fix bugs in the
earlier changes, are like feature patches to me. We're not adding
"new functionality" as George has put it, but only want to recover
some performance. And the switch to use INVPCID for flushing
was intended to be done independent of XPTI. So this very much
is a feature to me, instead of a bug fix.

Whether recovering performance is to be considered integral part
of earlier changes causing a loss of performance (especially when
that loss was expected) is an open question.

Jan


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