Message-ID: <87tttnhohp.fsf@gmail.com>
Date:   Fri, 28 Jul 2023 20:36:50 +0200
From:   Oscar Megia López <megia.oscar@...il.com>
To:     Markus Elfring <Markus.Elfring@....de>
Cc:     kernel-janitors@...r.kernel.org, linux-ext4@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Dan Carpenter <error27@...il.com>
Subject: Re: Contributing subsequent patch versions

Markus Elfring <Markus.Elfring@....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@...il.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

Powered by blists - more mailing lists