Hi Markus, On Wed, Jul 8, 2015 at 11:46 PM, SF Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx> wrote: >> Is there truly no way to simplify that process? > > I see some software development possibilities which could improve > the communication with high volume mailing lists. You shouldn't need any software development, most people's processes are: 1. Make changes 2. git add <files> 3. git commit 4. Repeat 1-3 for all changes they want to make 5. git-format-patch 6. git-send-email through some SMTP server to the list and appropriate other people >From what I've read, you appear to have some semi-automatic tool for steps 1 through 4. I'd strongly recommend changing your patch submission process to use git-format-patch and git-send-email. If Sourceforge's email system doesn't let you send emails with SMTP directly, then you might want to try sending emails through your ISP's mail server. Maintainers use a very similar process, however they collect and review patches in some personal repository in addition to making changes and committing them. Tools like patchwork are simply fancy methods of accumulating patches into git trees. Most people are using git-format-patch and git-send-email, possibly with some scripting around them, to format and send patches. >> You should be sending the patches directly with SMTP using git-send-email, > > This tool is also fine for the publishing of a lot of patches. git-send-email or some other tool? >> if you're not, then you're making things overly complicated for yourself. > > But I prefer a graphical user interface for my mail handling so far. I send my patches using git-send-email through gmail's servers then deal with literally everything else through gmail's web interface or Android app. Using git-send-email doesn't mean you can't use a graphical mail interface. I used to send patches through a carefully configured instance of Thunderbird, however this required too many steps and it loved to mangle patches in ways that annoyed people. >> Having a feature doesn't mean that it should be used. > > Does any of the "questionable functionality" get occasionally overlooked > a bit too often? It's not "questionable functionality", it's functionality we don't see a need for. If I wanted to, I could insert a patch at any point in the history of Linux in my own repository, however any attempt to push that upstream would cause enormous amounts of pain and annoyance, to everyone who attempted to deal with it, so I don't. Thanks, -- Julian Calaby Email: julian.calaby@xxxxxxxxx Profile: http://www.google.com/profiles/julian.calaby/ -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
