linux-kernel - Re: [PATCH v2] docs: add backporting and conflict resolution document

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <83fd1a05-974e-4d91-82b0-c09cc2f8da1e@oracle.com>
Date:   Fri, 13 Oct 2023 17:24:31 +0200
From:   Vegard Nossum <vegard.nossum@...cle.com>
To:     Jonathan Corbet <corbet@....net>
Cc:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, backports@...r.kernel.org,
        Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>,
        Bagas Sanjaya <bagasdotme@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        "Jason A . Donenfeld" <Jason@...c4.com>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        Steven Rostedt <rostedt@...dmis.org>, Willy Tarreau <w@....eu>
Subject: Re: [PATCH v2] docs: add backporting and conflict resolution document

On 10/10/2023 21:57, Jonathan Corbet wrote:
> Jonathan Corbet <corbet@....net> writes:
> 
>> Vegard Nossum <vegard.nossum@...cle.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.com/

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