Re: [GSoC] A late proposal: a modern send-email
On Tue, Mar 29, 2016 at 6:17 AM, 惠轶群 <huiyiqun@gmail.com> wrote:
Show 32 quoted lines
> 2016-03-29 0:49 GMT+08:00 Ævar Arnfjörð Bjarmason <avarab@gmail.com>:
>> On Sat, Mar 26, 2016 at 3:13 AM, 惠轶群 <huiyiqun@gmail.com> wrote:
>>> 2016-03-26 2:16 GMT+08:00 Junio C Hamano <gitster@pobox.com>:
>>>> 惠轶群 <huiyiqun@gmail.com> writes:
>>>>
>>>>> # 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.
Show 5 quoted lines
>> 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.
>> In this case it would mean shipping a statically linked OpenSSL since
>> that's what these perl SSL packages eventually depend on.
惠轶群
