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

[Julien Grall <julien@xxxxxxx>]

Hi,

On 06/12/2021 15:06, Jan Beulich wrote:
> 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?
This seemed to be implied by asking someone else to do it.

> 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. 
It is quite possible that this may have splipped in the previous review 
I have done. But now that I noticed it, I would like to confirm the 
signed-off-by was carried correctly.
> 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.
The problem is how a reviewer can verify you did carry the tags properly 
when porting?
I agree that with the copy/paste, we may add mechanical tags. But it is 
reducing the effort for both the reviewer as they only need to check 
against the commit.
> > 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.
Cheers,

--
Julien Grall