Scoping the UI changes for 2.0
Stephen J. Turnbull
stephen at xemacs.org
Wed Apr 29 09:51:18 BST 2009
Karl Fogel writes:
> How about this:
>
> > - a commitment to backwards compatibility and isolating users
> > from the effects of format changes.
My 2 yen:
Please, no. Do it Mark's way. Bazaar has manifested a strong
tendency to allow the UI to go to pot and promising new features to
languish while fiddling interminably with internal formats, and
addressing bugs and user problems associated with them. The life-
cycle cost of format development is known to be high, and your
proposal simply amounts to saying "let's pay more of that cost
*before* release rather than afterward."
If the current format really sucks that bad, git's is known to be high
performance in many contexts and it's bog-simple and hacker-friendly;
maybe the Bazaar developers can fix its Windows inefficiencies and win
big that way. Alternatively, Mercurial's format is known to be high
performance on all platforms and has an existing Python implementation
(it might be hard to add structures needed to support Bazaar features,
I dunno). AFAICS all of these can communicate via fastimport format,
so backward compatibility can be maintained at the expense of
performance if necessary.
But probably current Bazaar development format doesn't suck that bad.
Keep working steadily on optimizing transport for current formats, and
shift focus to
(1) shoring up the UI and
(2) getting the ReallyCool features polished up and documented.
More information about the bazaar
mailing list