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

[Juergen Gross <jgross@xxxxxxxx>]

On 29/03/18 12:50, Wei Liu 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.

And we still have the possibility of individual Release-Acks.

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

Right.

Still I think shifting by one week, given the current situation where
some maintainers had to spend a significant amount of the development
phase with security stuff instead of being able to review patches, is
a sensible thing to do.

So I think I'll do that with making it very clear that this won't be the
default process for the following releases.


Juergen

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