"submit" command naming - just "bundle" preferred?

[Adeodato Simó]

* Aaron Bentley [Thu, 19 Jul 2007 13:43:42 -0400]:

> Martin Pool wrote:

> > It's a good question.  It seems to me that producing a bundle is kind of
> > an implementation detail - when I do this, it's almost always because I'm
> > going to send it, and it's just an implementation limit that we don't
> > nicely invoke the mail client yet.

> For me, the main issue is configuration policy.
> 1. how do we set up the interactive client.  what are the alternatives?

First, I must say I'd find desirable to have the command capable of be
invoking the user's editor to write the body, and have bzr send the
message. I won't argue whether this should be the default mode or not,
just stating that it'd be nice to have.

Now, for spawning the user's prefered MUA to send the message, I propose
to use xdg-email program [1] from the FreeDesktop.org project. It will
check what desktop environment the user is running, and retrieve from
its configuration the preferred MUA, and invoke that. If none can be
found, it calls the configured browser with a mailto: link. xdg-email
accepts files to be attached.

  [1] http://portland.freedesktop.org/xdg-utils-1.0/xdg-email.html
      http://portland.freedesktop.org/wiki

> 2. how do we configure the target address?

I guess the answer is "in branch.conf". Pardon my ignorance then, but
how is this useful if that file is not copied when branching? (At least
it's not copied in the test I made.) I mean, the owner of the public
branch should be able to set the target addresses, no? How would that
work?

> > How about

> >  send -o OUTPUTFILE

> Given a send command that actually sends mail, this is pretty good.  -o
> will be rarely used, for sure.

I'm curious, what's the use case for send -o, instead of using bundle -o?

Cheers,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
        Listening to: Luis Eduardo Aute - Ay, ay, ay (todos en stand-by)