x86/hpet: Don't enable legacy replacement mode unconditionally

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

Ian Jackson writes ("Re: [PATCH v1.1 2/2] x86/hpet: Don't enable legacy 
replacement mode unconditionally"):
> Andrew Cooper writes ("[PATCH v1.1 2/2] x86/hpet: Don't enable legacy 
> replacement mode unconditionally"):
> > In addition, introduce a "hpet" command line option so this heuristic
> > can be overridden.  Since it makes little sense to introduce just
> > "hpet=legacy-replacement", also allow for a boolean argument as well as
> > "broadcast" to replace the separate "hpetbroadcast" option.
> 
> I'm sorry, but I think it is too late for 4.15 to do this.  I prefer
> Jan's patch which I have alread release-acked.

I think I have been perhaps insufficient clear.  Following discussions
earlier in the week, I made that fairly definitive statement this
morning.  There has been various discussion but I restated my postion
at 14:07 UTC today:

| I think the appropriate course, therefore, is the conditional (based
| on commaned line) revert proposed by Jan.

So to be 100% clear, this currently-still-being developed series is

Release-Nacked-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>


I have reviewed the more minimal patch provided by Jan.  I am
satisfied that it is correct.  I have reviewed the checkin policy in
MAINTAINERS.  Jan is a maintainer of this code, but a second approval
is also required.  Roger has provided a review and in any case I think
my approval may also be sufficient (either due R-B implying a REST
A-B, or due to it being a R-B by "anyone of suitable stature in the
community").

The policy says that:
  Sufficient time must have been given for anyone to respond
  There must be no "open" objections.

I think under the circumstances that these have been met.  At 12:59
UTC today I wrote:

| Andrew, I don't think you have, so far, Nak'd Jan's patch.  If you
| feel it warrants your Nak please provide it ASAP.

Andrew has not, in response to that specific invitation, nacked Jan's
patch.


Roger wrote:

> I would like to avoid such RB being seen as me deciding on which
> option is best release wise.

Indeed.  Thank you for being clear, Roger.

I think that this decision falls to me as Release Manaager.  I have
considered the question, taken input, and decided to take the more
minimal change.


Therefore I have just now pushed the more minimal command-line based
conditional disablement (to both staging and staging-4.15).  I would
like to see the more comprehensive and better fixes in xen-next, but
ideally to be committed there only after 4.15 is released, in case we
need to rework this area again as part of the release.

This is not necessarily the end of the conversation.  If the
Committers feel that my decision as Release Manager is wrong, I think
it is open to the Committers to overrule me, via a vote.


Ian.
current Xen Project Release Manager