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