[darcs-users] darcs UI: send = bundle file; send --mail = mail

[Ben Franksen]

Eric Kow wrote:
> On 23 Aug 2012, at 13:44, Eric Kow wrote:
>> On 21 Aug 2012, at 18:39, Florent Becker wrote:
>>> 
>>> Maybe there should not be a
>>> "default-configed-mailer-I-didn't-even-know-was-there". How about the
>>> following UI (modulo wording)?
>>> 
>>> #darcs send -a
>>> Creating patch to [destination repo]...
>>> I see you haven't configured 'sendmail-command' in ~/.darcs/config
>>> I don't know how to send this bundle, saving it as bundle.dpatch for 
now.
>>> NOTE: You may use your mail client to send this bundle.
>>> NOTE: If you want 'darcs send' to send a mail directly, add the line
>>> send sendmail-command COMMAND
>>> to your ~/.darcs/config
> 
> 
> Do we want something like this?
> 
> $ darcs setup send
> 
> What command does your computer use to send email? [try to detect]
> Please give me an email address to send a test message to [detect global 
darcs author]
> 
> Thanks! If all went well, you should receive a message with further 
instructions on
> setting up darcs send
> 
> (email instructions would mention the darcs config steps)
> 
> Then the idea would be to direct people to darcs setup send instead of 
giving them config instructions.
> I wonder if this sort of one-time setup mechanism generalises to other 
areas of darcs usage?

I would much rather have Darcs not send email by default (yes, I argued 
against it, but I begin to regret it), than start with this sort of creeping 
featurism. My experience is that Q/A style configuration seldom works well 
in practice, if only because the sort of question you want to ask cannot be 
answered easily out of hand. One needs to look up terms, read manuals, look 
at the existing configurations of other tools etc etc. One needs time to do 
such things in peace, being hurried along by a tool that asks heavy 
questions only leads to hasty and therefore erroneous answers. Then you have 
a botched configuration and how is the user to know how to reset it to 
defaults or how to correct false answers?

Furthermore, all this functionality tends to complicate Darcs *without* 
making it a better version control system. And don't forget that Darcs is a 
developer tool, not something targeted at computer novices. Anyone who uses 
Darcs will *at least* have enough experience editing text files, so if you 
give a hint to edit the personal preferences file this is completely 
adequate.

I have been arguing that by default Darcs should at least *try* to do what 
the command suggests. However, I would find it completely reasonable if 
'darcs send' w/o further arguments by default simply failed, with a message 
like

>darcs send
Sorry, I have no idea which mail program to use. Use option -O to just 
create a patch bundle, or give the --sendmail-command option.

or some such. It would help if the message could shortly explain how it 
expects the command to work, i.e. what it gets as argument and/or stdin; or, 
better yet, explain that in the manual, and give a link to the relevant 
chapter. At the moment, if I want to find out why 'darcs send' does not work 
I either have to debug this with a script that logs arguments/stdin, or else 
try to find the relevant code in the Darcs sources, neither of which is very 
user-friendly.

I would greatly prefer Darcs to concentrate on being the better version 
control system: the basic command set must be reliable, scale reasonably to 
large repositories and long histories, and the UI should be simple and 
consistent (enough work to do here, see my other message where I made a 
number of suggestions how to improve that).

Interaction with external tools is bound to be frought with hazards, so keep 
it simple, stupid, so users can handle/configure these tools as they see 
fit.

I hope you don't take this rant amiss, I am very fond of Darcs, and I do 
want it to become more user-friendly, but Q/A style auto-configuration is 
decidedly the wrong way to go IMO.

Cheers
-- 
Ben Franksen
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments