The cost of contributing (was: [MERGE] Explain --message and --mail-to in the help of merge-directive)

[James Westby]

On (28/06/07 16:55), Aaron Bentley wrote:
> James Westby wrote:
> > If no-one should be using them then that is fine. However I am not sure
> > why you say that. I use these options for the bundles I just sent in.
> 
> Yes, and as I noted, you are making extra work for me by doing that.  I
> would appreciate it if you would stop it.

Yes, I will do, my apologies.

> 
> > Could you explain the intended use of this command please?
> 
> $ bzr merge-directive > ~/patches/my-patch-name
> 
> Now create a message in your mail client and attach the merge-directive
> to it.

This is an extra step that --mail-to allowed me to avoid. That saving
made it seem like less effort to submit a patch, and prompted me to try
and fix some bugs.

Personally I find Bazaar's policies make it just a little too much work
to start sending in patches for everything that I come across. This is
partly due to the desire to have complete patches with tests, PEP-8 etc.
which are areas where I am still learning, and partly just the mechanics
of doing it. This means that when I send in a patch I normally expect a
couple of iterations before it is accepted.

I am not criticising the desire for reviews and good code and testing, I
think it is great, and is one of the reasons why I use the tool. However
I think the tool itself could make the mechanical process a little
easier.

With the workflow you propose I have to do the work, and make the
commit, then create the bundle, which takes a noticeable amount of time.
I then go to my MUA, and compose the message, and then have to navigate
to the bundle and select it.

What I likes about the --mail-to was that I could just write one
command, and run it, and then I could switch away to something else
while the task was done, without me having to wait. It's a small thing,
but it made a difference.

> 
> Some patches are so trivial that they don't need any explanation, but
> most of them deserve an explanation beyond what goes in the subject line.

Yes, that is true. I try and write good commit messages, but sometimes
that wont be appropriate either.

If we were to have a command that made all of this easy, perhaps it
could fire up an editor for you to write the body of the message, much
like commit does.

John Goerzen noted how darcs' 'send' command made the barrier to
submitting changes lower, and how bzr's current requirements might put
some people off. Creating a 'send' like command that knew where to send
the changes, the preferred format, and gave you a one shot way of
submitting might be something to consider.

Thanks for the reviews,

James

-- 
  James Westby   --    GPG Key ID: B577FE13    --     http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256