Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

From: Eric Wong <e@80x24.org>
Date: Aug 4, 2016, 20:17 UTC
Message-ID: <20160804201751.GA9592@starla>
In-Reply-To: <CAGZ79kaTT3NgKj8akB8t9b1BF3i6sXe7Un9oq5KP8077Wz-E+g@mail.gmail.com>

Stefan Beller <sbeller@google.com> wrote:

Show 8 quoted lines

> On Thu, Aug 4, 2016 at 8:58 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > I guess I have no really good idea yet, either, how to retain the ease of
> > access of sending mails to the list, yet somehow keep a strong tie with
> > the original data stored in Git.
> 
> Does it have to be email? Transmitting text could be solved
> differently as well.

I've thought a lot about this over the years still think email is the least bad.

Anti-spam tools for other messaging systems are far behind, proprietary, or non-existent. bugzilla.kernel.org has been hit hard lately and I see plenty of bug-tracker-to-mail spam as a result from projects that use web-based bug trackers.

And email spam filtering isn't even that great
(and I think it needs to be better for IPv6 and .onion adoption
 since much of it is still IPv4-oriented blacklisting).

I guess a blockchain (*coin) implementation might work (like hashcash is used for email anti-spam), but the ones I've glanced at all look like a bigger waste of electricity than email filters.

Of course, centralized systems are unacceptable to me; and with that I'll never claim any network service I run will be reliable :)