[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 1/7] xz: add fall-through comments to a switch statement
Jan Beulich writes ("Re: [PATCH 1/7] xz: add fall-through comments to a switch statement"): > I'm unwilling only as long as I don't understand the need for them. As > indicated, while I appreciate your "make verification easier for > reviewers", I assign that at least no higher priority than my desire > to leave out inapplicable data. Are we still talking about Signed-off-by ? I explained the purpose of Signed-off-by. It reflects the chain of custody. It is true that s-o-b is often added by people with minimal contribution to the content; I don't think that is relevant. If the Xen patch was derived from Linux commit XYZ (whether automatically or manually) then even those minimal S-o-b are applicable. > I'd be happy for anyone else to start over. I would even ack such a > submission myself. But as long as I'm recorded with S-o-b, I'm afraid > I'm not going to accept re-addition of the tags for no good (as per my > personal view) reason. Otherwise, based on experience, the example of > this series could, in the future, be used to tell me that on an earlier > occasion I (seemingly) did things differently. S-o-b does not indicate complete approval of the content. It attests precisely to the statements in the DCO. There is nothing irregular about putting your S-o-b on something you don't entirely agree with. Stepping back: In a collaborative project, we must all respect our peers and the community's decision. That can mean actively progressing patches that we personally disagree with, but which the community has decided ought to be applied. [1] I appreciate that can be less fun. But it comes with the territory of being a leading member of the community. > As said earlier, if submissions in this form are going to be nak-ed > going forward, and if good reasons (see above) will not be provided > (and hence leeway will not be granted to the submitter) to support this, > then someone else will need to start looking after imports which may be > relevant to us. The problem is simply one of verification. So far there does not seem to be a positive ack[1] for this patch. Neither I nor Julien are nacking it. AIUI Julien does not want to ack it without being able to check that all the appropriate s-o-b (and perhaps other tags) are present. I think that as the submitter it is really best if you make that easy. We think the obvious way to make that easy for a reviewer is to just copy the tags. But an alternative would be to include, in the commit message, full details of where the patch came from in (including urls to mailing list articles) in such a way that a reviewer can see easily that all the necessary s-o-b are present. [1] Of course very rarely there might be matters of conscience, where we have protested but our protest has been overruled by our peers. But that does not seem to be the case here since you are not giving a nak. Ian. [1] Julien did give one earlier but then wrote "actually" and started this subthread, so I think Julien has withdrawn his ack.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |