Re: [PATCH 2/7] docs/devel: add git-publish for patch submitting

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

On 11/19/24 01:12, Daniel P. Berrangé wrote:
> On Tue, Nov 19, 2024 at 09:41:40AM +0100, Marcin Juszkiewicz wrote:
>> W dniu 18.11.2024 o 18:23, Pierrick Bouvier pisze:
>>> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
>>> ---
>>>    docs/devel/submitting-a-patch.rst | 14 ++++++++++++++
>>>    1 file changed, 14 insertions(+)
>>>
>>> diff --git a/docs/devel/submitting-a-patch.rst b/docs/devel/submitting-a-patch.rst
>>> index 349c32ee3a9..953682f20cb 100644
>>> --- a/docs/devel/submitting-a-patch.rst
>>> +++ b/docs/devel/submitting-a-patch.rst
>>> @@ -237,6 +237,20 @@ attachments can be used as a last resort on a first-time submission.
>>>    .. _if_you_cannot_send_patch_emails:
>>> +Use git-publish
>>> +~~~~~~~~~~~~~~~
>>> +
>>> +If you already configured git send-email, you can simply use `git-publish
>>> +<https://github.com/stefanha/git-publish>`__ to send series.
>>> +
>>> +::
>>> +
>>> +    $ git checkout master -b my-feature
>>> +    $ # work on new commits, add your 'Signed-off-by' lines to each
>>> +    $ git publish
>>> +    $ ... more work, rebase on master, ...
>>> +    $ git publish # will send a v2
>>
>> You recommend 'b4 shazam' in 3/7 patch so why not here? Both 'b4' and
>> 'git-publish' seem to do same stuff - handle patch series and send them
>> upstream.
> 
> git-publish is what we already recommended to people both elsewhere in
> this file, and more prominently in the README.rst file, so maintaining
> that practice is correct.
> 

At the time I started working on QEMU, I missed that information, 
because I focused on the manual (missing the content of the README), so 
that's why I add it here as well.

>> b4 allows to keep To/Cc emails inside of cover letter which makes it easy to
>> not miss anyone needed.
> 
> git-publish automatically CC's people by correlating the files touched in
> the commits against our MAINTAINERS file, so it "does the right thing"
> in the majority of cases. We recommend it because it makes it much harder
> for novice users to mess up patch series submission.
>

I agree with that. From my personal experience, the hardest part when 
onboarding with email workflow is more to understand it (which steps you 
go through until the contribution is accepted), more than learning a 
specific tool in particular.
So having a "simple" tool like git-publish is good.

> With regards,
> Daniel