bundle in 0.19.0dev0 breaks compatibility with 0.18

[Dato Simó]

As part of the bundle -> submit -> send iteration, the `bzr bundle`
command has broken compatibility: in 0.18 (and every prior version),
bundle accepted the --output parameter, but would print to stdout if
--output was not given. Now --output is inconditionally required.

I think it would be best to make bundle and send separate commands,
sharing all the *current* options except --no-bundle via a common
function, and making bundle hidden, thus making `send -o` the
recommended interface from 0.19 onwards, but keeping bundle for current
users.

 affects /products/bzr
 status confirmed
 importance high

[Aaron Bentley (abentley)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adeodato Simó wrote:
> Public bug reported:
>
> As part of the bundle -> submit -> send iteration, the `bzr bundle`
> command has broken compatibility: in 0.18 (and every prior version),
> bundle accepted the --output parameter, but would print to stdout if
> --output was not given. Now --output is inconditionally required.

This is by Martin's request. I'm not going to mess with it any more,
and I'm certainly not going to do anything that would cause people to
use "bundle" instead of "send".
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGsAKw0F+nu1YWqI0RAl6cAJ0cl8W06Q1NBYq4tmrGvEXSvVgwbgCfYWoB
TjFEBTM7Q1wY5v3hvEVSmm8=
=Jr/X
-----END PGP SIGNATURE-----

[Dato Simó (dato)]

* Aaron Bentley [Wed, 01 Aug 2007 03:49:04 -0000]:

> Adeodato Simó wrote:
> > Public bug reported:

> > As part of the bundle -> submit -> send iteration, the `bzr bundle`
> > command has broken compatibility: in 0.18 (and every prior version),
> > bundle accepted the --output parameter, but would print to stdout if
> > --output was not given. Now --output is inconditionally required.

> This is by Martin's request. I'm not going to mess with it any more,

Martin, can you tell us if you realized bundle would break compatibility,
but wanted to carry on nevertheless, or it was just an oversight?

> and I'm certainly not going to do anything that would cause people to
> use "bundle" instead of "send".

Even if bundle is hidden and documentation updated?

[Alexander Belchenko (bialix)]

I think we need to deprecate `bundle` command and even will not treat it as alias to `send`, because there is many another different things between `bundle` and `send`

[Martin Pool (mbp)]

I didn't intend or expect that we would break the existing use of bundle. I wanted/expected both bundle and merge-request to remain, and eventually be deprecated in favor of send. I think we should not release without this fixed.

[Andrew Cowie (afcowie)]

All of our contributers are used to using `bzr bundle > file`. The fact that they have to manually attach that to an email they then thoughtfully author is a good thing; most of them do not have local MTAs set up (why would they?) and they are writing that email to the human maintainer (ie, me), not to some bot. I look forward to reading the email justifying why I should consider merging a patch, and said email is gracefully written in an email client.

You will, of course, do what you think best, but if I might be allowed to offer an opinion: if you want to encourage people to use `bzr send` then encourage people to use `bzr send`. Making `bzr bundle > file` harder to use with silly command line options is making Bazaar as a whole harder to use, and that doesn't seem like the direction you want to go.

AfC

[Martin Pool (mbp)]

On 8/6/07, Andrew Cowie <email address hidden> wrote:

> You will, of course, do what you think best, but if I might be allowed
> to offer an opinion: if you want to encourage people to use `bzr send`
> then encourage people to use `bzr send`. Making `bzr bundle > file`
> harder to use with silly command line options is making Bazaar as a
> whole harder to use, and that doesn't seem like the direction you want
> to go.

So concretely, you think that bundle should continue to write to
stdout by default (I do), and bzr send should... Not exist? Be an
alternative to bundle? Prompt for descriptive text before sending, or
run the user's mail client?

--
Martin

[Andrew Cowie (afcowie)]

Since I don't know what your goals for `bzr send` are, it's hard for me to comment, but the notion of firing the user's email client (be it evolution, kmail, thunderbird, whatever - the desktop should be configured so that it just works, right?) with the {bundle, whatever} already {inline, attached, or best of all patch inline and binary data containing the revisions as attachment} sounds good.

Won't hold you to it, though :)

I would note that for the cost of creating a discrete file on disk and the bother of an extra step to fire one's MUA and compose the message, there is the opportunity to glance fairly clearly at the patch being sent. That's usually a good thing, in my limited experience - quite frequently I see bundles with "oops, fix that" as the top revision.

AfC

[John A Meinel (jameinel)]

It would be really nice, the problem is that it is really tricky. There isn't really a standard for how to do it. You can use a "mailto://" url, but there isn't a standard spec on how to include an attachment with mailto.

So it pretty much comes down to customization per client. Which probably needs to be done with a config option, with some standard values for different MTAs. (I've figured out how to do it for Thunderbird, but it fails if T-bird is already running. So overall, that doesn't work very well).