I need help to send v2 patch on linux-ext4 at vger.kernel.org

I need help to send v2 patch on linux-ext4 at vger.kernel.org

[Oscar Megia López]

Hi

I have submitted a patch to linux-ext4 at vger.kernel.org mailing list
and they have responded with whatever changes they think are necessary.

Can someone help me by telling me the steps I need to take to send v2?
I don't know where ask it.

Do I have to create a new branch?

Is modifying the source in the same branch enough?

Do I have to do a git pull on the patch branch before the changes?

Do I have to to commit the changes before running
git format-patch --in-reply-to=20230423082349.53474-1-megia.oscar@gmail.com --cover-letter -o outgoing_v2/ master?

--in-reply-to= points to the v1 patch cover-letter or v1 1/1 mail?.

Please, is my first time to send a patch version's v2 and I didn't find
any place where explain step by step how to do it.

I tried several steps, but I get errors or resend v1 patch too.

-- 
Regards
Oscar Megia López

Re: Contributing subsequent patch versions

[Oscar Megia López]

Markus Elfring <Markus.Elfring@web.de> writes:

>> I have submitted a patch to linux-ext4 at vger.kernel.org mailing list
>> and they have responded with whatever changes they think are necessary.
>
> Do you refer to your change approach “e2fsck: Add percent to files
> and blocks feature” (from 2023-04-23) here?
> https://lore.kernel.org/linux-ext4/20230423082349.53474-2-megia.oscar@gmail.com/
>

Yes

>
>> Can someone help me by telling me the steps I need to take to send v2?
>> I don't know where ask it.
>
> Did you become more familiar with available development documentation
> and further information sources?

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.

>
>
>> Do I have to create a new branch?
>
> Probably, yes.
>
> You can manage as many topic or development branches as needed,
> can't you?

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.).

>
> See also:
> https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
>
>
>> Do I have to do a git pull on the patch branch before the changes?
>
> You can recheck if your development basis is still recent enough
> for your ideas.
>

Yesterday I did git pull on patch develop branch, commit v2 changes and I got this error:

$ LC_ALL=C git format-patch --base=auto --in-reply-to=20230423082349.53474-1-megia.oscar@gmail.com --cover-letter -o outgoing/ master
fatal: base commit should be the ancestor of revision list

I searched on the internet and found no solution.

That's why I asked about how send patch version v2. This command is similar
than v1 (only added --in-reply-to= because I read it on the internet to send
next versions).

>
>> Do I have to to commit the changes before running
>> git format-patch …
>
> Yes, of course.
>
> See also:
> https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_project_over_email
>

I asked this because the above error.

>
>> Please, is my first time to send a patch version's v2 and I didn't find
>> any place where explain step by step how to do it.
>
> Is the guidance usable by the document “Submitting patches:
> the essential guide to getting your code into the kernel”?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.5-rc3#n3
>
>

As I said before, I read this web page and much more,
but I didn't find the correct steps to submit next version.

I can do this on my way, but sure that I will make mistakes
(I'm not perfect and is my first time) and I don't want to disturb mantainers.

I search on e2fsprogs repository directory and I didn't find
any information about how send next patch's version.

I'm sure that this help to send next versions will be also good for all
newbies.

Here https://ext4.wiki.kernel.org/index.php/Ext4_Contributing I found
enought information to send first patch, but not for next version. The
page is quite old (2014) and I cannot contact with Djwong user.

>> I tried several steps, but I get errors or resend v1 patch too.
>
> Learning approaches will evolve as usual.
>

I create new branch and reseted to my v1 patch's commit and commited v2
changes. And when I ran:

$ git format-patch --base=auto --in-reply-to=20230423082349.53474-1-megia.oscar@gmail.com --cover-letter -o outgoing/ master                     
outgoing/0000-cover-letter.patch                                                                                      
outgoing/0001-e2fsck-Add-percent-to-files-and-blocks-feature.patch
outgoing/0002-e2fsck-Add-percent-to-files-and-blocks-feature.patch                                  
$

It didn't return previous error and also saved the previous patch and
I don't know if is correct to send previous patch's version.
I didn't see any v2 on ext4 maillist
https://www.spinics.net/lists/linux-ext4/maillist.html
sending previous version.

So I doubt I'm doing it correctly because git send-email will send
previous patch that I sent. I can delete this file but for me is not
correct way.

As I said before, if one of the lines I have changed has been changed
later, it would tell the maintainer that there is a conflict and
I don't want send wrong patch to maintaners.

I think it would be good to document how to send the next versions of
the patch. I am facing different problems and doubts, but I imagine that
the same will happen to other newbies like me.

I would like to have detailed documentation that tells me the correct
way to send the following versions of the patch. When there was no
internet you used to read the manuals when you wanted to learn new
things. Without manuals it is almost impossible to do something new
correctly without making serious mistakes. I learned MSX BASIC,
assembler, Turbo Pascal, Delphi, C, C++, linux, etc. reading manuals.

How am I going to learn without manuals?

It is beyond my imagination to read the mind of the one who created
those languages or OS. There are instructions that can be guessed,
but others cannot. Everything I have learned has been with manuals.

The same to send the following versions of the patch. If there isn't a
manual that says how to do it, I can try and I'm sure I'll make mistakes.
I send the patch and they don't accept it because it has errors, I try
again and I send it again with other errors and they won't accept it
because it has other errors, like this until all the maintainers block
me (with good reason).

I know you are very busy, so I offer to add this to the documentation
(for newbies) if someone tells me the correct steps in any case (if the
same lines have been modified since the previous version, if a link
needs to be added to the previous version(s) or if all versions are
shipped each time, etc.). I need all the steps to follow with the
example commands.

What I want is that nobody bothers you like me again, and if it bothers
you, you will only have to send them the link with the documentation
that I will create.

> Regards,
> Markus

-- 
Regards
Oscar Megia López

Re: Contributing subsequent patch versions

[Theodore Ts'o]

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

Re: Contributing subsequent patch versions

[Oscar Megia López]

Markus Elfring <Markus.Elfring@web.de> writes:

>> 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.
>
> Would you like to adjust this view any further?
>

I mean I haven't found the steps to submit v2 (and later) of a patch (as
v1 in https://ext4.wiki.kernel.org/index.php/Ext4_Contributing).

For instance (as far as I learned, but sure there are mistakes):

   1. Create a new branch from the v1 branch branch:
          Run git checkout patch_v1
          Run git checkout -b patch_v2
   2. Modify the sources for version v2.
   3. Commit the modified files with -s to add Signed-off-by: Your name
          <your email> at end.
   4. Run make to build or whatever.
   5. Test your changes.
   6. If everything is fine,
      Run git format-patch --base=auto --in-reply-to=[email id from
          patch_v1 (0/1 cover letter? or 1/1?)] [--cover-letter]? -o
          outgoing_v2/ master
      This will create three files (if you added --cover-letter
          parameter). I don't know if in patch's v2 is neccesary cover
          letter. The file starting by 0001- is patch's v1 (I am not
          sure if is necessary send patch's v1 or only link is enougth) and file
          starting by 0002- is patch's v2. You need to edit these files
          and add version changes after --- line (they are only
          information won't be on commit) from version to version.

   7. Run your patches through the kernel's style checker in scripts/checkpatch.pl
   8. Run path/kernel/linux/scripts/get_maintainer.pl path/yourPatch_v2/outgoing_v2/0002-patchSubject.patch
   9. Run git send-email --to="mailing list email" --cc="[emails from step 8 separated by commas (if any)], [other emails you want to send patch v2 separated by commas]" outgoing_v2/

At this point you will have sent the v2 patch to the --to and --cc
emails. If you don't use git send-email, note that emails to be sent to
mailing lists must be in plain text
(https://www.kernel.org/doc/html/latest/process/email-clients.html).

>
>> Today I found this
>> https://staticthinking.wordpress.com/2022/07/27/how-to-send-a-v2-patch/
>
> Such advices by Dan Carpenter are also helpful.
>
>
>> but I still have some doubts.
>
> Which concerns will need clarifications?
>

I don't know correct steps to send patch's v2 as above instance. Sorry,
but I need step by step instructions, if not I think that I can make
mistakes and I don't want. Sorry, but my experience says that is very
easy make mistakes when I am newbie.

>
>>> You can manage as many topic or development branches as needed,
>>> can't you?
>>
>> Yes, I know, but I want to know how an expert programmer send
>> next version
>
> Are you looking for more advanced development tools?
>

No, I just want to know how an expert programmer will do the task that I
need to do. I can try it myself with trial/error, but I'm not alone, am I?

>
>>               create new directory outgoing for each patch's version?,
>
> Corresponding name selections are influenced by some case distinctions.
>

I apologize if I said anything that was confusing (English is not my
native tongue). My question was if expert developers create a different
name for outgoing directory for each patch's version on
git format-patch ... -o outgoing/ master command.
For instance: -o outgoing_v1 for v1, -o outgoing_v2 for v2 and so on.
I ask this because you can lost patch files from previous
patches if you run this command several times (it makes backup ending
with ~, but usually last backup is lost after update). Or not?

>
>>               run git pull on patch's branch?,
>
> Software evolution (and their time ranges) can occasionally trigger special consequences.
>

So I undertand that is not neccesary. Right?

>
>>               add --in-reply-to= to previous patch's version email?
>
> Replies can generally be attempted according to previous messages
> (by different communication tools).
>
>

I apologize if I said anything that was confusing (English is not my
native tongue). My question was if is necessary add this parameter (--in-reply-to).

>
>> I create new branch and reseted to my v1 patch's commit
>
> I suggest to reconsider your imaginations around the need for “resetting”.
>

I apologize if I said anything that was confusing (English is not my
native tongue). I wanted to say that I created new branch from branch
for patch v1 to run git reset or whatever without modify branch patch
v1. If I make any mistake or something harmful I can checkout to
original branch for patch v1 and delete this test branch.

I think that is secure. Right?

>
>> and commited v2 changes. And when I ran:
>>
>> $ git format-patch --base=auto --in-reply-to=20230423082349.53474-1-megia.oscar@gmail.com --cover-letter -o outgoing/ master
>> outgoing/0000-cover-letter.patch
>> outgoing/0001-e2fsck-Add-percent-to-files-and-blocks-feature.patch
>> outgoing/0002-e2fsck-Add-percent-to-files-and-blocks-feature.patch
>> $
>>
>> It didn't return previous error and also saved the previous patch and
>> I don't know if is correct to send previous patch's version.
>
> You would probably like to present only improved information.
> Did a patch series become relevant then?
>

I apologize if I said anything that was confusing (English is not my
native tongue). I wanted to say that is not necessary send previous
patch v1 because I sent it before. For instance, if I send v20, is
necessary send 19 previous versions to mailing list? How usually is
managed? As format-patch do?, sending only last version with links to
previous versions? Sorry for my question, but I think that send again
the previous versions is not necessary and will saturate the mailing
list, but it is only my modest opinion, the important thing is how it is
usually done.

>
>> So I doubt I'm doing it correctly because git send-email will send
>> previous patch that I sent.
>
> Please reconsider the selection of desired data.
>

Sorry, could you explain me deeper what you mean?

>
>> How am I going to learn without manuals?
>
> Will any observations and experiments help to improve the understanding
> for desired activities?
>

Yes if I am doing something for me, but send patch to e2fsprog or
whatever involve more people and I don't want make many mistakes and
disturb others (I know you are very busy).

I learned sometimes without manuals and is very hard. I don't mind if
my mistakes are private. For instance, if learning something in my PC I
made a big mistake is my problem and my time to solve it, but if I made
a big mistake sending patches I will feel very bad because I made lost
time to others.

>
>> The same to send the following versions of the patch. If there isn't a
>> manual that says how to do it, I can try and I'm sure I'll make mistakes.
>
> Would you get into the mood to become also a technical writer?
> https://forum.linuxfoundation.org/discussion/863417/introduction-oscar-megia-lopez
>

Yes, I am interested in becoming a technical writer. I think I could be
a good technical writer because I want to explain everything thinking
that the people reading are newbies. Explain things in such a way that
no one has doubts. I know it is very difficult, but I like difficult
challenges. English is not my native language, so I will need someone
with English as a native language to verify my documentation.

I will surely make mistakes. I am only human.

This way I can improve my linux developer level and my English level, so
I would like (on my limited spare time).

>
>> I know you are very busy, so I offer to add this to the documentation
>> (for newbies) if someone tells me the correct steps in any case (if the
>> same lines have been modified since the previous version, if a link
>> needs to be added to the previous version(s) or if all versions are
>> shipped each time, etc.).
>
> How do you think about to extend another information source?
>
> Examples:
> * https://kernelnewbies.org/
> * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/
>

I would like very much. I would need someone to clear up my doubts or
correct my contributions. I think it's a good way to help the community
that I'm so grateful for and at the same time I would learn a lot of new
things about Linux and how to be a kernel developer. I think it's the
best way to start and we'll see how far I can go. My wish is to become a
kernel developer, but if I'm not good enough, I'll learn a lot of new
things, which is good too.

>
>> I need all the steps to follow with the example commands.
>
> This can be more convenient.
> Which of your experiences can you reuse already?
>

Above I wrote an example with 9 steps that I learned. I am not sure of
them and still I have some doubts.

>
>> What I want is that nobody bothers you like me again,
>
> We came along similar learning difficulties.
>

Thanks. I though that I was worse than the others.

>
>> and if it bothers you, you will only have to send them
>> the link with the documentation that I will create.
>
> This sounds promising.
>

Thanks.

> Regards,
> Markus

-- 
Regards
Oscar Megia López

Re: Contributing subsequent patch versions

[Theodore Ts'o]

On Fri, Jul 28, 2023 at 08:36:50PM +0200, Oscar Megia López wrote:
> I don't know correct steps to send patch's v2 as above instance. Sorry,
> but I need step by step instructions, if not I think that I can make
> mistakes and I don't want. Sorry, but my experience says that is very
> easy make mistakes when I am newbie.

We all make mistakes; don't worry about it!  This includes myself,
which is why I often will run:

      git format-patch -o /tmp/p -5

<then examine the patches in /tmp/p very carefully to make sure they make sense>

before I run

       git send-email /tmp/e --to linux-<subsystem>

where I have a bunch of aliases in ~/.mail_aliases, e.g.:

alias linux-ext4 Ext4 Developers List <linux-ext4@vger.kernel.org>
alias linux-fsdevel Linux Filesystem Development List <linux-fsdevel@vger.kernel.org>
alias linux-kernel Linux Kernel Developers List <linux-kernel@vger.kernel.org>
alias lkml Linux Kernel Developers List <linux-kernel@vger.kernel.org>
alias fstests fstests@vger.kernel.org
alias djwong Darrick J. Wong <djwong@kernel.org>
alias torvalds Linus Torvalds <torvalds@linux-foundation.org>

that way, I can just use a alias like "--to lkml" instead of having to
type linux-kernel@vger.kernel.org.

Now, do you *have* to do this?  No, of course not!  It's a short-cut,
which can use if it saves you time.


As far as wanting step-by-step instructions, the problem is that there
are always exception cases.  So it's very hard to have someone try to
anticipate every single contingency, and encode that in a step-by-step
recipe that someone follows blindly.

It's much more important that you understand *how* git works, for
example, and what might be happening at various steps, as opposed to,
"just give me the step by step formula and don't bother me with how
things works under the covers".

> No, I just want to know how an expert programmer will do the task that I
> need to do. I can try it myself with trial/error, but I'm not alone, am I?

Well, for something *really* simple, I might skep some of the steps.
That's because as an "expert" I understand what each of the steps are
doing, so I know when it might be safe to skip them.  For example, if
I'm only making spelling fixes in comments, I won't need to run
regression tests.  And to for a really, REALLY, simple patch, I might
not bother with checkpatch.pl --- but that's because I understand what
checkpatch.pl can and can't catch.

It also depends on what the maintainer wants.  In the case of fstests,
for example, the current maintainer doesn't mind making minor edits to
the commit before he applies it.  So I might not *send* a v2 version
of the patch, I'll just send a follow-up e-mail describing the typo
fixes that I failed to notice before sending out the patch.  For
example, see this email-thread:

   https://lore.kernel.org/all/20230727190512.357064-1-tytso@mit.edu/T/#u

In this particular case, it was pretty much "edit the Makefile", "git
commit -a", write up the commit, build fstests and make sure the
install worked properly, "git send-email -1 --to fstests --cc djwong".
There were no "9 steps", because I was in a hurry, and I knew when I
could skip some of the steps.


> I apologize if I said anything that was confusing (English is not my
> native tongue). My question was if expert developers create a different
> name for outgoing directory for each patch's version on
> git format-patch ... -o outgoing/ master command.
> For instance: -o outgoing_v1 for v1, -o outgoing_v2 for v2 and so on.
> I ask this because you can lost patch files from previous
> patches if you run this command several times (it makes backup ending
> with ~, but usually last backup is lost after update). Or not?

So *I* don't bother saving the older patch versions.  One of the
reasons for that is I have the older patches in my e-mail archives,
and I can find my e-mail archives much more quickly than I can
archiving other things.  Worse case, I can always search for older
versions of the patch set using https://lore.kernel.org, and I can
fetch previous versions of the patches via:

git am -o /tmp/m <message-id>

But that doesn't mean that there might not be *some* expert developers
who might keep older versions of the directories around.  Although to
be honest, in the case where I expect that I might need to resend a
patch series many times, I'd probably just have a series of branches
in git, named <topic>_v2, <topic>_v3, etc. and then it's not all that
hard to regenerate them using "git format-patch" if I really need
them.  (In actual practice, it's rare that I need refer to anything
but the immediate patch set, and only when I'm assembling toe
differences between the v<n-1> and v<n> patch set.  And most of the
time, I try very hard to keep my patch sets small, so I can usually
write the changes from memory, and I don't need to run diffs on the
patches.)

> >>               add --in-reply-to= to previous patch's version email?
> >
> > Replies can generally be attempted according to previous messages
> > (by different communication tools).

So in *general* I don't recommend adding an --in-reply-to for the
previous version of the messages.  If I need to find the earlier
versions of the patches, I'll just search for them on lore.kernel.org.
Having --in-reply-to= for older versions of the patches can sometimes
confuse the b4 program, and as a maintainer, I generally prefer to do
something like this:

     b4 am -o /tmp/m -c <message-id>

Where the -c option means, "check for newer versions of the patch
series".  But if you have later patch series set as a reply, and
one-line patch summaries have changed, this can sometimes confuse b4's
automated algorithms for determining when a patch is patch of a patch
series or not.

It's not a *disaster* if you do this; it just means more manual work
on my part.

> 
> I apologize if I said anything that was confusing (English is not my
> native tongue). I wanted to say that I created new branch from branch
> for patch v1 to run git reset or whatever without modify branch patch
> v1. If I make any mistake or something harmful I can checkout to
> original branch for patch v1 and delete this test branch.

Sure, one of the ways that I might do things is something like this:

    git branch topic_v2 topic

and then use a command like "git checkout topic_v2 ; git rebase -i
HEAD^^^" to edit the patches.  That is *one* way of doing things.


On the other hand, there has been times when I'll export the patches
as a patch series, e.g:

    git format-patch -o /tmp/p -7

and then edit the patches in /tmp/p, so I can use features like global
search and replace on the diff files, if I want to change the name of
a variable across multiple patches, and then reapply the patch series:

    # origin is the branch name I typically use for the base of my patch series
    git branch topic_v2 origin      
    git am /tmp/p


See?  There is no *one* way to do things.  They all have benefits and
tradeoffs.  Editing patches in a way that you don't break them such
that they don't apply is a bit of an advanced skill, and it's possible
that you can break things.  But as long as you know enough git
commands so that you are creating new branches and then modifying the
commits on the newer branches, it's actually pretty hard to lose data
with git.

> I apologize if I said anything that was confusing (English is not my
> native tongue). I wanted to say that is not necessary send previous
> patch v1 because I sent it before. For instance, if I send v20, is
> necessary send 19 previous versions to mailing list? How usually is
> managed? As format-patch do?, sending only last version with links to
> previous versions? Sorry for my question, but I think that send again
> the previous versions is not necessary and will saturate the mailing
> list, but it is only my modest opinion, the important thing is how it is
> usually done.

So in *general* it's pretty rare that you'll need to send that many
versions of the patch series to the list.  If you are getting to v20,
it may be a sign that you have too many patches in a patch series.  In
general, it's hard for people to maintain enough concentation to
review more than 6 to 10 patches in a patch series.  So see if you can
break up your patch series into smaller chunks.  An additional benefit
is if you're going in the wrong direction, you can course course
correct that much easier.

Most of the time, for complex patches, the cover letter will have
something like this at the end of the letter:

    v4
      * list of changes since V3
      * more changes
    v3
      * list of changes since v2
      * lorem ipsum...
    v2
      * list of changes since v1
      * ...

That's mostly because people are copying the cover letter from the
previous version and then editing it, and it's a bit eaisier to just
to add the list of changes since the last version, and it's extra
effort to delete the previous changes, so why not?

						- Ted

Re: Contributing subsequent patch versions

[Oscar Megia López]

"Theodore Ts'o" <tytso@mit.edu> writes:

> 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
>

Thank you very much, Ted. That's what I was asking. I don't see the
point in bothering to send the second version (which I've never done) if
there's someone who knows how to do it and is willing to help. I tried
it by myself and searching the internet and I didn't find the right way.

Thanks for your time, Ted.

I really apreciate your help.

> 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

Ok, if you don't think it's necessary, I won't send the v2.

Yesterday I realized that I made a *BIG* mistake: I sent the email to the
wrong list. I wanted to send the email to the list linux-kernel-mentees
because I think it is the right place to ask these questions and not
bother the kernel developers, but no harm comes from good. In this way
Markus has told me tasks that I can do to start help the community.

Thanks Markus!

Sorry for sending the message several times with the subject: "I know
you are busy, but have you found time to look at my patch?" to the
linux-ext4 mailing list, but the first time I sent it from web site
https://mail.google.com and I got this response: "Content-Policy reject
msg: The message contains HTML subpart, therefore we consider it SPAM or
Outlook Virus. TEXT/PLAIN is accepted.!", so I tried to send the message
with other mail clients and I didn't see the message in
https://www.spinics.net/lists/linux-ext4/maillist.html looking for
megia.oscar or Oscar Megia López, so I tried several times believing
that you did not receive it. On Friday I realized that you did receive
it. I have seen it in https://lore.kernel.org/linux-ext4/?q=megia.oscar

I apologize for repeatedly sending that email inadvertently. It was not
my intention.

-- 
Regards
Oscar Megia López

Re: Contributing subsequent patch versions

[Oscar Megia López]

"Theodore Ts'o" <tytso@mit.edu> writes:

> On Fri, Jul 28, 2023 at 08:36:50PM +0200, Oscar Megia López wrote:
>> I don't know correct steps to send patch's v2 as above instance. Sorry,
>> but I need step by step instructions, if not I think that I can make
>> mistakes and I don't want. Sorry, but my experience says that is very
>> easy make mistakes when I am newbie.
>
> We all make mistakes; don't worry about it!  This includes myself,
> which is why I often will run:
>
>       git format-patch -o /tmp/p -5
>
> <then examine the patches in /tmp/p very carefully to make sure they make sense>
>
> before I run
>
>        git send-email /tmp/e --to linux-<subsystem>
>
> where I have a bunch of aliases in ~/.mail_aliases, e.g.:
>
...

Thank you very much Ted for your help and your time. I really appreciate
it.

I apologize for my doubts, but I've always been told that I'm
different because I doubt everything. Sometimes is good and sometimes is
not good.

In my experience, I believe that asking for help from someone who knows
much more is the right way to act when you don't know how solve issue.

-- 
Regards
Oscar Megia López

Re: Contributing subsequent patch versions

[Oscar Megia López]

Markus Elfring <Markus.Elfring@web.de> writes:

>> Sorry, but my experience says that is very easy make mistakes
>> when I am newbie.
>
> Which kind of errors would you like to produce if you would become
> an “expert” (like a system tester) in additional areas?
>
> Regards,
> Markus

I don't know, but what I've observed during my years working in IT is
that I come up with tests that no one else does. This way I find bugs
that no one else finds.

For example, I forked the project https://github.com/pixel/hexedit and
tried to find errors. I found many, such as what happens if you try to
load a very long filename, what happens if you try to load a very large
file, etc. I fixed them all, but because maintaner didn't accept my
first patch, I didn't carry on.

If anyone is interested in me testing their patch, I would love to do
it. Now I'm reading LINUX KERNEL DEBUGGING book (written by Kaiwan N
Billimoria) and I'm on chapter about strace and some tools like lttng,
so I can use these tools mentioned on book to test patches.

-- 
Un saludo/Regards
Oscar Megia López

Re: Contributing subsequent patch versions

[Markus Elfring]

> Thank you very much, Ted. That's what I was asking. I don't see the
> point in bothering to send the second version (which I've never done)

I find such feedback interesting and surprising somehow.


> if there's someone who knows how to do it and is willing to help.

It is occasionally nicer to get direct hints from more experienced
users (or developers) instead of performing additional research.


> I tried it by myself

I imagine that corresponding experimentation can be improved further.
Did you send any messages only to yourself
(or a customised data / software analysis system) before?


> and searching the internet

You found some advices by Dan Carpenter at least.
https://staticthinking.wordpress.com/2022/07/27/how-to-send-a-v2-patch/


> and I didn't find the right way.

There are more possibilities available for further development considerations.


>> 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?
…
> Ok, if you don't think it's necessary, I won't send the v2.

Would you like to take another look at any more information sources?

Example:
https://en.wikipedia.org/wiki/Storage_Management_Initiative_%E2%80%93_Specification


> Yesterday I realized that I made a *BIG* mistake: I sent the email to the
> wrong list.

It seems that you demonstrate growing learning experiences.


>             I wanted to send the email to the list linux-kernel-mentees
> because I think it is the right place to ask these questions and not
> bother the kernel developers, but no harm comes from good.

The selection of message recipients can also be challenging.


> In this way Markus has told me tasks that I can do to start help the community.

I became curious then how contributions will evolve accordingly.

Regards,
Markus
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

Re: Contributing subsequent patch versions

[Greg KH]

Hi,

This is the semi-friendly patch-bot of Greg Kroah-Hartman.

Markus, you seem to have sent a nonsensical or otherwise pointless
review comment to a patch submission on a Linux kernel developer mailing
list.  I strongly suggest that you not do this anymore.  Please do not
bother developers who are actively working to produce patches and
features with comments that, in the end, are a waste of time.

Patch submitter, please ignore Markus's suggestion; you do not need to
follow it at all.  The person/bot/AI that sent it is being ignored by
almost all Linux kernel maintainers for having a persistent pattern of
behavior of producing distracting and pointless commentary, and
inability to adapt to feedback.  Please feel free to also ignore emails
from them.

thanks,

greg k-h's patch email bot

Re: Contributing subsequent patch versions

[Greg KH]

Hi,

This is the semi-friendly patch-bot of Greg Kroah-Hartman.

Markus, you seem to have sent a nonsensical or otherwise pointless
review comment to a patch submission on a Linux kernel developer mailing
list.  I strongly suggest that you not do this anymore.  Please do not
bother developers who are actively working to produce patches and
features with comments that, in the end, are a waste of time.

Patch submitter, please ignore Markus's suggestion; you do not need to
follow it at all.  The person/bot/AI that sent it is being ignored by
almost all Linux kernel maintainers for having a persistent pattern of
behavior of producing distracting and pointless commentary, and
inability to adapt to feedback.  Please feel free to also ignore emails
from them.

thanks,

greg k-h's patch email bot
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees