Message-ID: <CAGRGNgU+1xsdXe9aTYCVvowbo-w9s7chcaNphzzdB2xsuXOBxA@mail.gmail.com>
Date:	Thu, 9 Jul 2015 09:47:43 +1000
From:	Julian Calaby <julian.calaby@...il.com>
To:	SF Markus Elfring <elfring@...rs.sourceforge.net>
Cc:	Frans Klaver <fransklaver@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Chris Park <chris.park@...el.com>,
	Dean Lee <dean.lee@...el.com>,
	Johnny Kim <johnny.kim@...el.com>,
	Rachel Kim <rachel.kim@...el.com>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	Julia Lawall <julia.lawall@...6.fr>,
	kernel-janitors@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Clarification for the use of additional fields in the message body

Hi Markus,

On Wed, Jul 8, 2015 at 11:46 PM, SF Markus Elfring
<elfring@...rs.sourceforge.net> 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@...il.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists