[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
Julien Grall writes ("Re: [PATCH 1/7] xz: add fall-through comments to a switch statement"): > On 06/12/2021 16:12, Jan Beulich wrote: > > 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 still have have no way to verify > what you did is correct. I can't believe this is still outstanding. I think I understand Julien's position, and I agree with what I have understood. In particular, I think I understand why Julien feels it necessary to make an issue of this. The Signed-off-by lines are there to help provide assurance that we aren't making legal mistakes. They need to be verifiable by a reviewer. So that means that when a patch's own declaration of its origin is "this patch came from Linux commit XYZ" then all the S-o-b in that Linux git commit should be retained. If the patch came from somewhere else, eg a mailing list post, I think it would be OK to say something like "this patch came from lmkl, [url to posting], and has since been committed to Linux as [commitid]~". In that case the S-o-b should match the mailing list posting, but the Xen patch being posted must then be identical to the mailing list posting. IOW it should be a deterministic process to start with the patch's declaration of where it came from (or which sources it came from), and verify that 1. the patch really did come from there and 2. all of the approriate tags, especially S-o-b, are present. By far the easiest way to achieve this is to take the patch from Linux git using (eg) git-cherry-pick. git will automatically DTRT. [1] I don't have as strong an opinion about other tags, eg ones indicating approval in Linux. However, I think the overwhelming majority of people would think it conventional to transfer all of the tags from the original commit even if they are irrelevant in the new context. I don't understand Jan's position. Jan, why are you fighting so hard to delete these tags ? What practical harm does its presence do ? [1] Jan, I know that you don't use git very much. I think this is a great shame. I find it perplexing to see how anyone can work without it. The git command line UI is indeed terrible, but by now almost everyone has either bitten the bullet of learning it, or adopted one of the overlay UI packages that now exist. (Personally I did learn the cli but am starting to forget git cli nonsence since now I do almost everything with magit inside emacs.) I think the time has long passed when it is reasonable for a key Xen developer to ask others to do additional work, or deal with anomalies, in order to accomodate an unwillingness to use git. Obviously we all have our own workflows, but git has heavily influenced our shared norms (and data formats). If someone chooses not to use git, they must at least be able to pretend. Sorry, Ian.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |