George Dunlap writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."): > On the other hand, I think there's a bit of a faulty interpretation of > the procedure here. Jan reviewed the patch thoroughly and then acked > it; on the basis of that, Konrad legitimately checked it in. After it > was checked in Jan said, "I've changed my mind and withdraw my Ack"; > and the assumption of the subsequent conversation was that an ack > *can* be withdrawn after it has been legitimately checked in, and that > if no other Ack is supplied, then it must be reverted. > > I don't think that's a correct interpretation of the rules. Reviewers > in general, and maintainers in particular, should make reasonably sure > that they mean the Ack before they give it; and if they change their > mind after it has been legitimately checked in, then it's now up to > them to make the change they want to see according to the regular > procedure.
For the record, I agree completely with George here. I was expecting that the next step would be to for Jan to post patches to revert the extra hypercall and replace it with something else. Jan Beulich writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was: > And btw., considering that Konrad has already posted a revert patch, > and I have ack-ed that one, this could now go in right away (and the > discussion could either be settled or start over). I don't see that patch you describe in my inbox, but maybe I have missed it. If that reversion is proposed, following a request for a 2nd/3rd opinion from me and George, and given the discussion so far, I think that patch ought to have been CC'd to me and George. I don't think it would be appropriate to commit a revert except as part of a series which introduces an replacement way of providing the needed functionality - at least, enough functionality that in practice a plausibly long build-id can be retrieved. If you want the original reverted, I think it is up to you, Jan, to provide (or procure) such a replacement. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel