|
[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
On 06.12.2021 15:28, Julien Grall wrote:
> On 06/12/2021 13:44, Jan Beulich wrote:
>> On 26.11.2021 13:52, Ian Jackson wrote:
>>> Jan Beulich writes ("Re: [PATCH 1/7] xz: add fall-through comments to a
>>> switch statement"):
>>>> On 26.11.2021 11:04, Julien Grall wrote:
>>>>> For this case, you provided some sort of an explanation but so far, I am
>>>>> still waiting for a link to confirm that the signed-off-by match the one
>>>>> on the ML.
>>>>
>>>> I haven't been able to easily find a mail archive holding this patch.
>>>
>>> I 100% agree with Julien on all points in this thread.
>>>
>>> Please can we keep the Linux S-o-b.
>>>
>>> Note that S-o-b is not a chain of *approval* (whose relevance to us is
>>> debateable) but but a chain of *custody and transmission* for
>>> copyright/licence/gdpr purposes. That latter chain is hightly
>>> relevant to us.
>>>
>>> All such S-o-b should be retained.
>>>
>>> Of course if you got the patch somewhere other than the Linux commit,
>>> then the chain of custody doesn't pass through the Linux commit. But
>>> in that case I expect you to be able to say where you got it.
>>
>> I've submitted v2 with S-o-b restored as far as necessary to meet this
>> requirement. I did not restore all of them, because I continue to not
>> see the value of retaining them. You saying "is highly relevant to us"
>> is a statement, but not an explanation of why tags beyond those in the
>> original submissions need retaining.
>>
>> Without me seeing the need / value, I'm afraid I see only two ways
>> forward: Either things are acceptable as they are now (and will be for
>> future similar imports), or it needs to be someone else to put time
>> into spotting and then pulling in such changes.
>
> I am a bit confused how this would require more time. They are already
> in the commit message from Linus's git and you have a correct commit id.
> So this is merely a copy/paste.
I didn't say "more time", did I? What I did (indirectly) say is that for
areas like this one it looks like I'm the only one to check at least
every once in a while. This has been working straightforwardly in the
past, but is now suddenly causing issues. And as indicated - if I would
understand the importance of tags which got mechanically added on the
way of flowing into Linux, I would likely be willing to give up my
position of viewing such extra tags as more getting in the way than
being helpful (much like I would always strip Cc: tags before committing,
as I firmly believe they have no place in the repo). But such an
explanation hasn't been given so far.
> 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.
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |