Scoping the UI changes for 2.0

[Karl Fogel]

Mark Shuttleworth <mark at canonical.com> writes:
> Somehow, we have come to a point that the Bazaar community thinks it's OK for
> there to be more than 10 formats "out there in common use", multiple
> development formats (6!!), rich-root and non-rich-root formats, and all sorts
> of bad interactions with network servers of various versions.
>
> During the 3.0 cycle, I would like to see:
>
> - a sprint and design focus on the command UI
> - a commitment to having ONE stable format throughout, and ONE development
> format EVER in 3.0,

(Hope the below isn't a redundant point.  I read the rest of the thread
to see if anyone else discussed this, and no one did, but it might be in
another thread somewhere...)

The issue is not that Bazaar has multiple formats.  Rather, it's the
fact that users have to *care* about formats.  If Bazaar insulated users
from format changes, then format changes wouldn't be such a big deal.

But because Bazaar's storage format is its wire format too, there is no
intermediary protocol providing an opportunity for compatibility shims,
and for graceful degradation of performance and even functionality.
Instead, if both sides don't support the same format, it's game over.

When two formats are semantically incompatible then no intermediary
protocol can fix that.  But many format changes are about performance
more than semantics.  Bazaar often *could* translate one format to the
other, but just doesn't do that.  Instead, it stops the show if one side
doesn't support the format the other one requires.

This is brittle.  True, it brings us a feature: you can push a branch to
a location without a smart server listening at that location.  But we
could retain that feature and still have smart servers do the
appropriate compatibility translation when present.  The story would
then be "If you want compatibility with as many Bazaars as possible,
install a server."  Major sites such as Launchpad would, of course, use
a smart server, so the most frequently accessed branches would also be
the most compatible ones.

Case study:

Subversion's wire protocol is 100% unrelated to its storage formats.
The wire protocol is extensible, and has been extended many times, but
always backwards-compatibly: if a client or server doesn't upgrade, then
at the most it simply doesn't get some new feature.  All the *old*
features and behaviors are still there, and of course upgrading just one
side still brings bug fixes.

Thanks to this, there have been Subversion releases that completely
rewrote storage mechanisms, and no user had to notice.  When this was
done for performance reasons, the wire protocol hid the changes
entirely: users don't know, admins don't care, ignorance is bliss.  When
done for feature reasons (i.e., there are semantic differences), there
are still compatibility shims offering graceful degradation and
admin-optional filters/blocking -- as opposed to completely disallowing
communications from the get-go.

Bazaar could continue to change formats as needed, if it arranges things
so that users don't have to notice.

So instead of this:

> - a commitment to having ONE stable format throughout, and ONE development
> format EVER in 3.0,

How about this:

> - a commitment to backwards compatibility and isolating users from the
> effects of format changes.

-Karl