On 03/29/2018 11:35 AM, Jan Beulich wrote: >>>> On 29.03.18 at 12:22, <george.dun...@citrix.com> 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. Well ultimately things take a non-deterministic amount of time; so we can either choose "We must release by this date" and drop all features not ready, or we can choose "We must release with this feature" and slip until it's ready.
In general, people seem to prefer the former; and from an administrative point of view it's certainly simpler than trying to determine which feature will be blockers. That said, it may make sense to argue that specific features / patchsets should be blockers in exceptional circumstances. > 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". As Wei said, bug fixes are always potential blockers (which is the point of the freeze). Are you thinking here specifically about the performance improvements, or about some new functionality (which I haven't noticed / heard of yet)? If you're talking about the performance patches, how do we know when we're "done"? Are we going to accept only patches / improvements in the current series, or are we going to allow people to add new techniques they come up with until we can't think of any more? Or until we reach a specific performance level? FWIW I do think getting the current XPTI performance improvement series in for this release makes a lot of sense. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
