launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

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

On 11-01-06 03:16 PM, Robert Collins wrote:
> So I changed that to support news_merge and bzr-builddeb both of which
> generate messages which are often insufficient/incorrect; there needs
> to be a way to support a user not wanting to continue (and hitting
> ctrl-C cancels an entire process, not a good model for GUI's).

For GUIs, the typical implementation would be a "cancel" button somewhere.

For consoles, ^C isn't a perfect answer, but it's been working just fine
for me.

> We can change the contract further if needed to support lp-land, but I
> haven't seen a bug describing how it doesn't work for lp-land.

I explained the issues to you directly in a thread entitled "Why do you
hate lp-land?" in November.

> Oh, and a small extra note: the behaviour in the prompt is *identical*
> to the previous behaviour when no commit message hooks were invoked -
> if the user exited with an unsable message the returned message was
> empty and higher level code looked for that

FWICT, "" was not a special value.  It just got a string from the user,
and  if the user provided an empty string, that's what it returned.  If
there was code to treat "" specially, surely it was because "" is not a
very informative commit message, not because it had any special meaning.

> - that is why the change I
> made returned an empty message, the calling code in bzr, bzr-gtk,
> bzr-explorer did not need to change. If lp-land wasn't handling empty
> messages as per the contract I can understand it getting confused, but
> it was already incorrect.

Until your change, the only way for edit_commit_message to return "" to
lp-land would be if the user manually deleted the prepopulated
'[r=foo][ui=none]' stuff.  I disagree that such handling is incorrect;
if the user chooses to supply an empty message, PQM will deem it
unacceptable.  We don't need to look before we leap and replicate PQM's
validation logic in lp-land.

I believe that a user cancellation would be best handled by raising an
exception.  This will ensure all callers abort, even outdated ones.
Up-to-date callers can then distinguish between "" and cancellation.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0mLPEACgkQ0F+nu1YWqI09XwCeMt8H/5xb6WfqGmfqnpHFHhEn
g4cAoIGONYW/q7KVP32JBjwfryne5lYO
=uP6o
-----END PGP SIGNATURE-----