3 ms·

1. make change in git, commit it with a good message. 2. call ./scripts/get_maintainer.pl -f on the file you changed 3. call git send-email -1 --cover-letter

1. make change in git, commit it with a good message. 2. call ./scripts/get_maintainer.pl -f on the file you changed 3. call git send-email -1 --cover-letter --annotate and tell it where to send the patch. 4. done This is significantly easier than clicking a bunch of buttons on a slow Github or Gitlab instance.

lxe 6y ago
This is easy indeed! But knowing is half the battle I guess... Most mainstream devs already "know" github/gitlab/etc, so having a process that supports people's existing workflow would be a good thing.
viraptor 6y ago
You forgot `0. setup outbound mail`. Which may include figuring out how to setup a smartrelay. Which for some provider leads to explicitly enabling mail submission and generating a separate auth token for your email provider. Which you will need to learn about by searching multiple pages. Ah, and if you're in a corp environment, forget about sending anything out on port 25 - you'll need to figure out a proxy as well. If you're working with that project every day - sure, that's trivial. If you're sending a drive-by patch useful to others, it's really in the project's best interest to make it as easy as possible. In at least one case I ended up sending an email like "This is a patch, it's in public domain now, your change process is so annoying I'm not going to spend the next hour to set it up, KTHXBYE".
- JdeBP 6y ago
  I have a couple such on my WWW site. (-: But in fairness edent's problems were finding out who to address the mail to and how to format the message, not how to actually use electronic mail in the first place; and one might as well note that the procedure is also missing "learn how to plug in a keyboard" and "learn how to edit C source code", if one is going to take it that far.
edent 6y ago
0. Set up git. Not always easy on a public computer. There are other prerequisites. I wrote up a guide a few years ago https://shkspr.mobi/blog/2014/04/submitting-trivial-linux-kernel-patches/ https://shkspr.mobi/blog/2014/04/submitting-trivial-linux-ke... 5. Go back and forth discussing the patch. Let other people contribute. Significantly easier on GitHub/Lab.

lxe 6y ago

This is easy indeed! But knowing is half the battle I guess... Most mainstream devs already "know" github/gitlab/etc, so having a process that supports people's existing workflow would be a good thing.

viraptor 6y ago

You forgot `0. setup outbound mail`. Which may include figuring out how to setup a smartrelay. Which for some provider leads to explicitly enabling mail submission and generating a separate auth token for your email provider. Which you will need to learn about by searching multiple pages. Ah, and if you're in a corp environment, forget about sending anything out on port 25 - you'll need to figure out a proxy as well. If you're working with that project every day - sure, that's trivial. If you're sending a drive-by patch useful to others, it's really in the project's best interest to make it as easy as possible. In at least one case I ended up sending an email like "This is a patch, it's in public domain now, your change process is so annoying I'm not going to spend the next hour to set it up, KTHXBYE".

JdeBP 6y ago
I have a couple such on my WWW site. (-: But in fairness edent's problems were finding out who to address the mail to and how to format the message, not how to actually use electronic mail in the first place; and one might as well note that the procedure is also missing "learn how to plug in a keyboard" and "learn how to edit C source code", if one is going to take it that far.

edent 6y ago

0. Set up git. Not always easy on a public computer. There are other prerequisites. I wrote up a guide a few years ago https://shkspr.mobi/blog/2014/04/submitting-trivial-linux-kernel-patches/ https://shkspr.mobi/blog/2014/04/submitting-trivial-linux-ke... 5. Go back and forth discussing the patch. Let other people contribute. Significantly easier on GitHub/Lab.