Re: [PATCH 1/7] xz: add fall-through comments to a switch statement

[Julien Grall <julien@xen.org>]

Hi,

On 07/12/2021 09:11, Jan Beulich wrote:
> On 06.12.2021 17:21, Julien Grall wrote:
>> Hi Jan,
>>
>> On 06/12/2021 16:12, Jan Beulich wrote:
>>> On 06.12.2021 17:06, Julien Grall wrote:
>>>> On 06/12/2021 15:06, Jan Beulich wrote:
>>>>> On 06.12.2021 15:28, Julien Grall wrote:
>>>>>> I am not going to ack it but I am also not going to Nack it if another
>>>>>> maintainer agrees with your approach.
>>>>>
>>>>> FTAOD I'll be giving it a week or so, but unless I get an outright NAK,
>>>>> I'm now in a position to put this in with Luca's R-b.
>>>>
>>>>    From the check-in policy section in MAINTAINERS:
>>>>
>>>> 4. There must be no "open" objections.
>>>>
>>>> So I think this cannot be check-in given two maintainers disagree on the
>>>> approach. That said, as I wrote earlier my condition for not Nacking is
>>>> another maintainer agree with your approach.
>>>
>>> Hmm, I did address both your and Ian's concerns in v2, admittedly by only
>>> going as far as minimally necessary. I therefore wouldn't call this an
>>> "open objection".
>>
>> I believe my objection is still open.
> 
> I've taken note of this. I'm afraid with the long winded discussion no
> other maintainer will provide an ack. Which therefore makes what you said
> above effectively a nak anyway. Unless things move in unexpected ways, I
> will have to consider this series rejected then.

The code is itself is fine. I would be fine to ack them so long I can 
verify the tags you carried.

As I wrote multiple time the easiest way here it to copy/paste them. 
They may be meaningless to you but it is going to save a lot of time for 
me to verify you carried the tags correctly.

But see more below.

>> I still have have no way to verify
>> what you did is correct.
>>
>> For instance, the tags in patch #2 are:
>>
>> Link: http://lkml.kernel.org/r/20191104185107.3b6330df@tukaani.org
>> Reported-by: Yu Sun <yusun2@cisco.com>
>> Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
>> Acked-by: Daniel Walker <danielwa@cisco.com>
>> [Linux commit: 8e20ba2e53fc6198cbfbcc700e9f884157052a8d]
>>
>> The tags in the Linux commit are:
>>
>> Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
>> Reported-by: Yu Sun <yusun2@cisco.com>
>> Acked-by: Daniel Walker <danielwa@cisco.com>
>> Cc: "Yixia Si (yisi)" <yisi@cisco.com>
>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>>
>> * The first two matches the original e-mails
>> * I couldn't find the 3rd on the ML.
> 
> See e.g.
> 
> https://yhbt.net/lore/all/20191108202754.GG18744@zorba/t/
> 
> (Andrew Morton's reply at the bottom) for where it originates.

Ok... So this is taken from a different aggregator. I will have to brush 
by search engine skill then.

> 
>> * The Cc could be ignored
>> * The signed-off-by are I guess what you call "mechanical"
> 
> I would generally retain Reviewed-by when our code is still quite
> similar to Linux'es. Acked-by are on the edge of being useful, but as
> you can see I did err on the side of keeping it. As said in a number
> of places elsewhere, for what I call mechanically added tags I am yet
> to be told of their value (or even need) in our tree.

I think the question is how difficult to do you want to make to the 
other reviewers? I appreciate other (including myself) may have ignored 
the tags in the past. But now that I know you do it as a manual process, 
it makes me a lot more nervous to simply ack such patch without any check.

You seem to be unwilling to simply copy/paste them. So for this series, 
would you be happy if someone else do it for you?

Cheers,

-- 
Julien Grall