[rfc] developer documentation on user interaction

[Vincent Ladeuil]

>>>>> "Stephen" == Stephen J Turnbull <stephen at xemacs.org> writes:


<snip/>

    >> Here bzr devs *want* bzrlib to be used.

    Stephen> """
    Stephen> You can't always get what you want
    Stephen> But if you try some time
    Stephen> You just might find
    Stephen> You get what you need
    Stephen> """
    Stephen>     -- Mick Jagger, trying to achieve an expression of Pythonic Zen

Mick as a python Zen monk is an interesting picture :)

    Stephen> Anyway....  I read Alexander as saying that bzrlib
    Stephen> is not very usable for him, for a couple of reasons,
    Stephen> including instability of the interface.  I'm just
    Stephen> pointing out that it is quite possibly true that the
    Stephen> bzr CLI is more stable and therefore programs using
    Stephen> it are more maintainable.

That was certainly true until a certain threshold for both qbzr and
say, olive (of bzr-gtk).

But qbzr is now entering into a phase where it wants more control
on many more pieces of bzrlib. As a consequence, we see more
tensions, some of them are due to that design choice. I think
it's worth discussing how to best address these problems because
I see more feature requests from qbzr popping up and these
features are already available from bzrlib but not from the bzr
CLI...

    >> And if I had more free time on my hands I certainly try to make
    >> emacs use bzrlib instead of bzr

    Stephen> Interesting.  That's what Alexander said.<wink>

Alexander use emacs ? Scoop ! <wink>

    Stephen> 2.  The audience for the CLI demands stability;
    >> 
    >> As in: "I don't want to test which version I'm using so don't
    >> change anything there or I'm doomed" ?

    Stephen> The audience I'm talking about here is Russel, Ben, and Maritza, not
    Stephen> Alex.

Oh my, misunderstanding there.

No wait, who is misunderstanding what ? Are you implying that the
bzr CLI should be used by humans only ? <wink>

    Stephen> And yes, I think they'd agree that they don't want
    Stephen> to have to do "bzr --version" on an unfamiliar host
    Stephen> in order to know what to tell the new dev they're
    Stephen> mentoring how to use bzr's CLI.  Don't you agree?

Of course I agree. bzr CLI will always have more stability than
bzr API, because people don't have regression tests so we need to
take more care of them :)

    >> So, I think "practicality beats purity" here, means, let's use
    >> bzrlib and stop pretending using bzr is the right way to go for
    >> wrong reasons ;)

    Stephen> No, that's not what it means.

Oh I definitely got your point and may be even some of its hidden
meanings <wink> 

But I thought I could (ab)use your citation anyway :)

        Vincent