Message-ID: <20230728181014.GA607743@mit.edu>
Date:   Fri, 28 Jul 2023 14:10:14 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Oscar Megia López <megia.oscar@...il.com>
Cc:     Markus Elfring <Markus.Elfring@....de>, linux-ext4@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Contributing subsequent patch versions

On Fri, Jul 28, 2023 at 08:22:22AM +0200, Oscar Megia López wrote:
> Yes, I read
> https://www.kernel.org/doc/Documentation/process/submitting-patches.rst
> yesterday and more online documentation and I didn't find any describing the
> correct way to send next patch version.
> 
> Today I found this
> https://staticthinking.wordpress.com/2022/07/27/how-to-send-a-v2-patch/
> but I still have some doubts.

What you're running into is the fact that there are multiple ways that
people will prepare patch versions, and so the process documentation
merely specify what the patch series should look like.

> Yes, I know, but I want to know how an expert programmer send
> next version (create new branch for each patch's version?, create new
> directory outgoing for each patch's version?, run git pull on patch's
> branch?, add --in-reply-to= to previous patch's version email?
> ¿cover letter or 1/1?, etc.).

Not only do many experienced programmers might have different
perferred workflows, they might use different procedures depending on
how complex the patch series would be.  For example, for the case for
a single patch, I'd probably just use "git format-patch -1 ...",
meaning "just format the top-most patch on the current branch".

For a really simple patch, I might just use "git commit --amend" to
make changes, and I might not bother rebasing unless it was necessary
to make sure it would apply on the top of the development branch.  If
it was necessary to rebase, assuming that you have the local branch
"origin_<topic>" which points as the base to your patch or patch
series, then what *I* typically do is just do:

git branch -f orgin_<topic> origin/master
git rebase origin_<topic>

Now the topic branch is rebased on the tip of the upstream development
branch, and now I might just do:

git format-patch -o /tmp/p origin_<topic>..

For a single patch, I might not bother with cover letter, and most of
the time, I'll just manually copy the cover letter from the previous
version into the current cover letter, append the description of what
changed from the last version, and then I'll send it out.

This just uses all basic git commands.  There *are* more sophisticated
systems that will automate things, and it's completely up to you
whether or not you want to use them.  Sometimes, the simpler methods
are best and systems which try to "automate" things can just confuse
you.

If you want to see an example of a much more sophistcated system, take
a look at the b4's "prep" command[1].  I don't use it, my self,
although I do use "b4 am" and "b4 ty" for my maintenance work.  So
don't feel like you have to use "b4 prep"; try it out, and see if it
makes your life easier.  If so, use it!  If not, just let it go, and
try something else.

[1] https://b4.docs.kernel.org/en/latest/contributor/prep.html

Finally, with respect to your original patch.  My apologies for not
looking at it eariler.  I'm pretty swamped these days, which means
that I'm prioritizing which patches get my attention.  As far as this
particular patch, I don't think it's actively harmful, but I also
don't quite see the point.  If you want to see how full a file system
might be, and it's disappearing too quickly because shortly after fsck
finishes, the graphical login has come up, you can always use the "df"
command, right?

						- Ted

Powered by blists - more mailing lists