Message-ID: <87tttlncib.fsf@gmail.com>
Date:   Sun, 30 Jul 2023 08:23:40 +0200
From:   Oscar Megia López <megia.oscar@...il.com>
To:     "Theodore Ts'o" <tytso@....edu>
Cc:     Markus Elfring <Markus.Elfring@....de>, linux-ext4@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Contributing subsequent patch versions

"Theodore Ts'o" <tytso@....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

Powered by blists - more mailing lists