[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 |