user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
From: Eric Wong <e@80x24.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Stefan Beller <sbeller@google.com>,
	meta@public-inbox.org, git@vger.kernel.org
Subject: Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]
Date: Fri, 19 Aug 2016 22:35:47 +0000	[thread overview]
Message-ID: <20160819223547.GB16646@dcvr> (raw)
In-Reply-To: <alpine.DEB.2.20.1608191720040.4924@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 18 Aug 2016, Eric Wong wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > Old dogs claim the mail list-approach works for them. Nope. Doesn't.
> > > Else you would not have written all those custom scripts.
> > 
> > git and cogito started as a bunch of custom scripts, too.
> 
> The difference is that neither git nor cogito were opinionated. Those
> custom scripts are. They are for one particular workflow, with one
> particular mail client, with a strong bias to a Unix-y environment.
> 
> I work really hard to make Git for Windows as easy and fun to use as
> possible. I just wish that we were working together to make it as easy and
> fun to contribute to Git, too.

I guess this is a fundamental difference between *nix and
Windows culture.

I enjoy using and contributing to git because it interacts well
with generic tools.  *nix kernels are optimized for this with
decent (not great)[*] process spawning and IPC performance.

I know Windows users have major performance problems with
shell scripts; but they are also largely helpless to improve
Windows kernel performance.

So, I guess monolithic tools became popular on Windows, instead.

> > I see a choice of mail client as no different than a choice of
> > text editor.  Neither my mail client or text editor is heavily
> > customized.  The key feature I rely on from both tools is piping
> > data to external commands.
> 
> There you go. That key feature seems to be unavailable in the most
> wide-spread email client: Outlook. So by not restricting the choice you
> should make it possible to use that mail client, too, right?
> 
> We do not even have a section on Outlook in our SubmittingPatches.
> 
> Okay, if not the most popular mail client, then web mail? Nope, nope,
> nope. No piping *at all* to external commands from there.
> 
> So you basically slam the door shut on the vast majority of email users.

Users have a choice to use a more scriptable mail client
(but I guess the OS nudges users towards monolithic tools)

It's unfortunate the world is so full of proprietary things;
but I think it's our responsibility as Free Software developers
to encourage the use of Free (or "Open Source") tools which
users can control.

> That is not leaving much choice to the users in my book.

Users of alpine, gnus, mutt, sylpheed, thunderbird, kmail,
roundcube, squirelmail, etc. can all download the source, hack,
fix and customize things.  It's easier with smaller software,
of course:  git-send-email does not even require learning
the build process or separate download.

<snip stuff Stefan already covered>

> > Users ought to be able to pick, choose, and replace tools as
> > they wish as long as an interchange format remains stable
> > and widely-supported.
> 
> Right. Let's talk about the interchange format called mails, for the data
> called patches. Is it stable and widely-supported?
> 
> Can users really pick and choose the tools they like most to send patches
> to the Git project? Like, the Outlook client? Or the GMail client?

Personally, I don't mind patches as MIME attachments if that
avoids corruption, MIME seems well-supported at this point.
It's not my call, though.  But as Stephan pointed, Linus
does it, too.



[*] Guess what: I have performance problems with fork/execve on
    Linux, too.  However, Linux developers already provide
    mechanisms to improve spawn performance (CLONE_VFORK and
    vfork(2)); so the next step is to get userspace like dash,
    make, perl, etc to support these.

    glibc 2.24 was just released with an improved posix_spawn
    for Linux (using CLONE_VFORK), so that's a step forward and
    might make sharing code with Windows easier, too.

    It's not a high priority for me at the moment, but I intend
    to get everything in my toolset which relies on fork+execve
    to use posix_spawn or vfork+execve instead.  I have the
    source to all of these, so at least I can do something
    about it.

  parent reply	other threads:[~2016-08-19 22:35 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-16 16:55 Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path] Stefan Beller
2016-08-16 17:10 ` Junio C Hamano
2016-08-16 17:20   ` Jeff King
2016-08-16 17:54     ` Junio C Hamano
2016-08-16 17:22   ` Stefan Beller
2016-08-16 17:47     ` Junio C Hamano
2016-08-16 20:44   ` Eric Wong
2016-08-16 20:56     ` Eric Wong
2016-08-18 12:42 ` Johannes Schindelin
2016-08-18 20:49   ` Eric Wong
2016-08-18 21:41     ` Junio C Hamano
2016-08-19 15:18       ` Johannes Schindelin
2016-08-19 15:30     ` Johannes Schindelin
2016-08-19 16:55       ` Stefan Beller
2016-08-19 22:35         ` Eric Wong
2016-08-22 13:38         ` Johannes Schindelin
2016-08-22 19:21         ` Jeff King
2016-08-19 22:35       ` Eric Wong [this message]
2016-08-22 13:18         ` Johannes Schindelin
2016-08-22 18:05           ` Jakub Narębski
2016-08-25 13:21             ` Johannes Schindelin
2016-08-28 18:23               ` Jakub Narębski
2016-08-29 10:46                 ` Johannes Schindelin
2016-08-22 22:55           ` Eric Wong
2016-08-25 12:58             ` Johannes Schindelin
2016-08-27 22:38               ` Jakub Narębski
2016-08-28  8:36                 ` Working with public-inbox.org Johannes Schindelin
2016-08-28 11:41                   ` Jakub Narębski
2016-08-29  5:35                     ` Johannes Schindelin
2016-08-19 15:03   ` Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path] Jeff King
2016-08-20 19:57     ` Jakub Narębski
2016-08-23  4:47       ` Arif Khokar
2016-08-24 15:34         ` Johannes Schindelin
2016-08-24 18:49           ` Eric Wong
2016-08-24 19:12             ` Jeff King
2016-08-24 19:27               ` Eric Wong
2016-08-25  3:40             ` Arif Khokar
2016-08-25  2:41           ` Arif Khokar
2017-02-10 16:10           ` Johannes Schindelin
2017-02-13  5:52             ` Arif Khokar
2017-02-13 14:37               ` Johannes Schindelin
2017-02-14  3:56                 ` Arif Khokar
2017-02-14  3:59                   ` Arif Khokar
2017-02-14  7:13                   ` Eric Wong
2017-02-13 19:21               ` Junio C Hamano
2017-02-14  3:55                 ` Arif Khokar
2017-02-14  4:41                   ` Junio C Hamano
2017-02-14  5:09                     ` Arif Khokar
2017-02-14  5:14                     ` Jeff King
2016-08-22 13:06     ` Johannes Schindelin
2016-08-22 13:15       ` Duy Nguyen
2016-08-22 20:38         ` Philip Oakley
2016-08-24 13:04           ` Johannes Schindelin
2016-08-24 19:16             ` Eric Wong
2016-08-25 13:08               ` Johannes Schindelin
2016-08-25  3:57             ` Arif Khokar
2016-08-25 13:01               ` Johannes Schindelin
2016-08-25 23:14                 ` Arif Khokar
2016-08-26  8:08                   ` Johannes Schindelin
2016-08-27 22:26         ` Jakub Narębski
2016-08-28  8:38           ` Johannes Schindelin
2016-08-28 13:45             ` Announcing Git User's Survey 2016 [was: Working with public-inbox.org] Jakub Narębski
2016-09-09 13:06               ` Johannes Schindelin
2016-09-09 18:51                 ` Jakub Narębski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://public-inbox.org/README

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160819223547.GB16646@dcvr \
    --to=e@80x24.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=meta@public-inbox.org \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/public-inbox.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).