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

[John Arbash Meinel]

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

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>> Aaron Bentley wrote:
>>> But does the world really need another mail client?  Especially when
>>> mutt behaves like that already?
>> mutt does, but Mail.app, Thunderbird, Outlook, Evolution.... there are lots of
>> mail programs out there that people prefer to mutt. (I don't know whether pine
>> does/doesn't, but it seems like it could). And consider using 'gmail' :)
> 
> Right.  And I figure people who don't prefer mutt won't like it if
> Bazaar gives them a mutt-like interface instead of using their mail client.

Except they probably like $EDITOR or they wouldn't be using it.

And trying to figure out how to control all possible MUA is a bit difficult. So
as a stepping stone between *nothing* and properly popping up their preferred
MUA with all attachments ready to go, I think $EDITOR is a decent stepping
stone. It is better than what we have (as in I might actually use it).

> 
>>>> 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 doesn't seem to be installed on my Etch.  Is it very popular?
>> It sounds like it would be useful if it was available.
> 
> Agreed.  It would be a good starting point for mailer support.
> 
>>> That's not really what I was asking.  Given that we'll use our normal
>>> configuration mechanism, what values will we use?  How's the policy
>>> supposed to work?
>> Sure, this is something that:
>> http://bazaar-vcs.org/SubmitByMail
> 
>> was meant to address.
> 
>> I think what we discussed (all the way back in Montreal), was that we would
>> have 2 values. One for the email address that *I* will send to when using this
>> branch, and one that other people who branch from me should use. Though it
>> would probably be sufficient in a first pass to have a single value that just
>> propagated by 'bzr branch'.
> 
> Maybe it's a YAGNI at this point, but I'd kinda like this command to
> work both for mailing list submission and for PQM submission.
> 
> bzr send --review <--- send a merge request to the ML via my mail client
> bzr send --apply <--- send a merge request to PQM a la pqm-submit
> 
> And I'm caught between overgeneralizing, and overspecializing.
> 
> Don't want too get too specific to us.

Yeah, I think some of it is just making PQM be a little bit more flexible.
Certainly we have had a few discussions that e-mail really isn't the best
interface for submitting to a bot. An XML-RPC interface would at least let you
get quicker feedback as to if the request is even accepted.

I could also see a potential bot do a cursory download before accepting your
request. To make sure it has what you are really requesting.

It could even go one step further, and merge the request to check for 'trivial'
conflicts. (Like conflicts in NEWS). There is a little bit of voodoo, in that
if there is a queue, it doesn't know whether the current patch is going to be
accepted.

But if we could make merge fast enough, I could see it merging against:

a) Whatever the last pristine commit was, and warning the user if that would
fail. (It may not reject it from the queue, but the user could at least be
warned that it is unlikely to succeed).

b) Apply all pending merges in the queue, and for all of them that "succeed" at
the merge test, you have a possible target. The idea is that you merge the new
patch assuming all other patches will succeed. This could also be used as a
warning, to let the user know "if all the patches in the queue succeed, then
your patch will fail to merge".

Certainly it could also only apply patches that merge cleanly, with a pseudo
commit in between. Heck, if it wanted to be fancy about it, it could do this
pre-merging + committing, then checkout one of the test commits, run 'make
check', and if it passes, it just updates the branch pointer. And then goes on
to the next.

I have the feeling it isn't worth trying, though, because the merge + commit
time is trivial compared to the time it takes to run the test suite. Especially
considering that 'make check' runs the full test suite 3 times.

> 
>>> Will the mail attachments have sensible names?  Can I configure Bazaar
>>> to stick them in a particular directory instead of a temp one?
>> I would think we should create temporary ones, send them, and then delete them
>> once they are sent. So it seems to make more sense to always put them in temp.
> 
> Well, then, we have a problem of knowing when it's safe to delete the
> patch.  With GUI clients, it's hard to know when the mail's been sent.

That is true. I think we certainly could come up with approximately reasonable
names for the attachments. And you could have a config for whether to put them
in $TMP or elsewhere. Though I would guess that is a bit YAGNI. TMP is meant
for files like this. I suppose if you submit thousands of large patches on
windows your TMP might fill up. Most Linux machines I use clean TMP
occasionally. (I've seen it wipe on startup, and RedHat actually has a script
that runs every day, deleting anything that has an access time older than 2
weeks or so, though it was a bit surprising when it started deleting files from
my $ARCH revlib on a machine I hadn't logged into for a while.).

> 
>> We could certainly come up with a way to name them (branch-nick + revno +
>> $RANDOM + .patch).
> 
> Actually, the branch-nick + revno would be unique enough.  It's only
> going to affect those who download/save the patch.
> 
> Aaron

It is close to random enough, but does mean that you might clobber an existing
file. $REVISION_ID would be sufficient, but a bit long. nick+revno might be
enough, with a $NICK-$REVNO$EXTRA, where $EXTRA = '', or -1, -2, -3... in case
we get a collision.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGn+LEJdeBCYSNAAMRApPVAKCuliLWGdIxvWgKUYLeh9gxLeCH3ACg0MTG
BMSgWBVX7vkkBhGR7v/jRuc=
=04mJ
-----END PGP SIGNATURE-----