On 10/10/2023 21:57, Jonathan Corbet wrote:
Jonathan Corbet corbet@lwn.net writes:
Vegard Nossum vegard.nossum@oracle.com writes:
This is a new document based on my 2022 blog post:
https://blogs.oracle.com/linux/post/backporting-patches-using-git
Although this is aimed at stable contributors and distro maintainers, it does also contain useful tips and tricks for anybody who needs to resolve merge conflicts.
By adding this to the kernel as documentation we can more easily point to it e.g. from stable emails about failed backports, as well as allow the community to modify it over time if necessary.
I've added this under process/ since it also has process/applying-patches.rst. Another interesting document is maintainer/rebasing-and-merging.rst which maybe should eventually refer to this one, but I'm leaving that as a future cleanup.
[...]
- I would like to see an ack/reviewed-by tag by others with experience with this task if possible. The lack of complaints is a good start, but not always indicative of a lack of disagreement...:)
I tried to include people and lists who might be interested in Ccs.
I've now added Steven Rostedt and Willy Tarreau as well on the off-chance that they have something to say about it (Steven presented his conflict resolution method at Kernel Recipes and I think Willy is experienced with backporting), but this is in no way meant as pressure to review this patch. Here's a link to the top of the thread:
https://lore.kernel.org/all/20230824092325.1464227-1-vegard.nossum@oracle.co...
I feel like in the worst case, somebody sees the document down the line and vehemently disagrees with something and we either fix it or take it out completely.
I'd like to add that my impression is that a LOT of people *fear* backporting and conflict resolution -- and it doesn't have to be that way. We should be talking about merge conflicts and what good workflows look like (one of the reasons why I was very happy to see Steven's presentation at KR), instead of leaving everybody to figure it out on their own. This document is my contribution towards that.
- Might this be better placed in Documentation/maintainer?
I can see the justification for that, given that maintainers probably resolve merge conflicts more than plain contributors. However, this was intended primarily as a guide to backporting stable patches, which is not primarily done by subsystem maintainers, as far as I know. I'm not sure where that leaves us. I thought it kind of fit next to "applying patches" under process/ but I trust the documentation maintainer's judgment :-) In either case, we can always move it (again) later.
- Colordiff looks cool, but I'd at least drop in a mention of the Emacs ediff mode, which offers (I believe) a lot of the same functionality.
I don't use emacs personally, but I would welcome this addition if somebody were to write it!
So I never got an answer on any of this ... I've gone ahead and applied the patch on the theory that it clearly hasn't upset anybody; I do still think we should consider moving it to the maintainer manual, though.
Thanks.
I also saw a bot complaint about a repeated word; can you fix it up, do I send a v3, or do I send an incremental patch?
Vegard