Markus Elfring <[email protected]> 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/[email protected]/
>
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 [email protected] --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 [email protected] --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
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
"Theodore Ts'o" <[email protected]> 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