Re: [GSoC] A late proposal: a modern send-email

On Tue, Mar 29, 2016 at 6:17 AM, 惠轶群 [off-list ref] wrote:

2016-03-29 0:49 GMT+08:00 Ævar Arnfjörð Bjarmason [off-list ref]:

quoted

On Sat, Mar 26, 2016 at 3:13 AM, 惠轶群 [off-list ref] wrote:

quoted

2016-03-26 2:16 GMT+08:00 Junio C Hamano [off-list ref]:

quoted

惠轶群 [off-list ref] writes:

quoted

# Purpose
The current implementation of send-email is based on perl and has only
a tui, it has two problems:
- user must install a ton of dependencies before submit a single patch.
- tui and parameter are both not quite friendly to new users.

Is "a ton of dependencies" true?  "apt-cache show git-email"
suggests otherwise.  Is "a ton of dependencies" truly a problem?
"apt-get install" would resolve the dependencies for you.

There are three perl packages needed to send patch through gmail:
- perl-mime-tools
- perl-net-smtp-ssl
- perl-authen-sasl

Yes, not too many, but is it better none of them?

What's more, when I try to send mails, I was first disrupted by
"no perl-mime-tools" then by "no perl-net-smtp-ssl or perl-authen-sasl".
Then I think, why not just a mailto link?

I think your proposal should clarify a bit who these users are that
find it too difficult to install these perl module dependencies. Users
on OSX & Windows I would assume, because in the case of Linux distros
getting these is the equivalent of an apt-get command away.

In fact, I'm not familiar with the build for OSX or Windows.

The core of your proposal rests on the assumption that
git-send-email's implementation is problematic because it has a "ton
of dependencies", and that this must be dealt with by implementing an
alternate E-Mail transport method.

But you don't go into how this is a practical issue for users exactly,
which is the rest of the proposal. I.e. "make it friendly for users".
Let's leave the question of creating an E-Mail GUI that's shipped with
Git aside.

Correct me if I'm wrong but don't we basically have 4 kinds of users
using git-send-email:

1) Those who get it from a binary Windows package (is it even packaged there?)
2) Also a binary package, but for for OSX
3) Users installing it via their Linux distribution's package system
4) Users building it from source on Windows/OSX/Linux.

I'm in group #3 myself for the purposes of using git-send-email and
have never had issues with its dependencies because my distro's
package management takes care of it for me.

I don't know what the status is of packaging it is on #1 and #2, but
that's what I'm asking about in my question, if this becomes a
non-issue for those two groups (if it isn't already) isn't this
question of dependencies a non-issue?

I.e. why does it matter if git-send-email has N dependencies if those
N are either packaged with the common Windows/OSX packages that most
users use, or installed as dependencies by their *nix distro?

 Group #4 is small enough and likely to be a git.git contributor or
distro package maintainer anyway that this issue doesn't matter for
them.

quoted

If installing these dependencies is hard for users perhaps a better
thing to focus on is altering the binary builds on Git for platforms
that don't have package systems to include these dependencies.

Why `mailto` not a good choice? I'm confusing.

I'm not saying having this mailto: method you're proposing isn't good
in itself, I think it would be very useful to be able to magically
open git-send-email output in your favorite E-Mail client for editing
before sending it off like you usually send E-Mail.

Although I must say I'd be seriously surprised if the likes of git
formatted patches survive contact with popular E-Mail clients when the
body is specified via the body=* parameter, given that we're sending
pretty precisely formatted content and most mailers are very eager to
wrap lines or otherwise munge input.

I'm mainly trying to get to the bottom of this dependency issue you're
trying to solve.

quoted

In this case it would mean shipping a statically linked OpenSSL since
that's what these perl SSL packages eventually depend on.