How can we ensure Bazaar (bzr) remains active?

[Stephen J. Turnbull]

Kevin Carrasco writes:

 > Git is the winner by a extremely large margin, but that doesn't make it 
 > the best; in fact, I feel it's 3rd in ranking for true history/revision 
 > tracking (Bzr first, Hg second, Git third).

Sure, but in the market it's not about you and Russell, it's about
everybody.  The problem Bazaar faces is that some of us think git has
the right of it for history/revision tracking (it's the only VCS that
destroys commits only in garbage collection, neither Bazaar nor
Mercurial can claim that ;-), and most of the rest don't care.
Nobody's out to "kill off" Bazaar or Mercurial (as Russel put it);
it's just that to the great majority of currently active VCS
developers, git is a far more attractive platform than either Bazaar
or Mercurial to work on.  As for resources, the corporation giveth,
and the corporation taketh away.  Nobody's giving resources to git to
kill off anything; they give resources to git because they think it's
the best way to improve their development environment at the moment.

 > Hg is still holding on, it's still very active, and has considerable 
 > projects using it.

It's losing ground in the market, though it has some pioneering
features (phases, for example) and is actively maintained and
extended.  Emacs didn't even consider it when it switched away from
Bazaar, nor did Mailman.  Even for Python itself a move to git is in
the air (Guido van Rossum has admitted to lusting in his heart for
GitHub-like features, and no, he's looked at Launchpad and laughed,
and at Bitbucket and concluded "no chance").  It's not going to happen
tomorrow, but it's not going to wait for Python 4[1], either, unless
some Mercurial-using "forge" grows GitHub-competitive services.

 > Is this the most realistic alternative to Bzr users who don't like
 > Git?

You didn't ask me :-), but my take is that Tom Lord had the right idea
when he abandoned Arch/tla and started work on revc: build on the git
object database and DAG utilities, and do a better UI.  For a new
version of Bazaar, this has the following advantages: (1) no need for
a repo conversion, just suck it in and add Bazaar-specific metadata;
(2) somebody else maintains the DAG-tracing and maintenance utilities;
(3) somebody else maintains the object compression stuff; (4) somebody
else maintains (most[2]) of the network protocol for cloning and
pulling; and (5) it disciplines you to avoid the format-fiddling and
resultant backward compatibility maintenance costs that Bazaar spent
significant resources on over the years.[3]

Note that the killer app for this approach is <sound src="drumroll"/>

... wait for it ...

... wait for it ...

... GitHub!

Think about it. :-)

AFAICS, to add explicit directory tracking, you could maintain
complete database file layout compatibility with upstream git by using
the directory bit in the mode.  Exporting back to git would be simply
a matter of stripping subdirectory entries from "tree" objects.[4]
Adding explicit move and copy tracking probably would require
additional metadata, which could be stored somewhere in the GITDIR (or
in .bzrdata under git control, at first).

I don't really understand what's "correct" about Bazaar's branching
model, so I don't have a concrete suggestion there.  But ISTM that the
DAG underlying Bazaar's model is the same as git's (git *does* order
the parents of a merge commit in the parent list, even though it
mostly doesn't bother the user about "correct" choice of order).  So
"all you need to do" :-) is to embed the relevant invariants in the UI
(or more likely an intermediate "plumbing layer" API).

Bazaar's design is sufficiently layered that this may be relatively
easy to do (ie, plug the various DAGgy and networky components in as
implementations of the corresponding internal APIs), and thus you may
very well *not* need a complete rewrite.

 > But should we really abandon one of the only DVCS offerings that's 
 > actually part of the GNU project,

<snort/>  A true marriage of convenience on both sides.

 > is almost completely Python-based, was designed instead of built
 > (Git's slop of pieced together commands and scripts is not a
 > purpose-built design),

No, but the underlying "the DAG's not the main thing, it's the only
thing" design is the main reason git has a 10-try[5] lead in the
market.  Sorry, but that's the way things go:

    https://www.dreamsongs.com/WorseIsBetter.html

 > As of now, I'm using both Bzr and Hg actively...  but I'm only
 > promoting Bzr to see if we can put some life back into it.

Don't "promote Bzr" to the public, nobody's going to listen (unless
they work for you).  Instead, review the submitted branches already in
the tracker, and "promote" the best of them.  Then write more.  Or
maybe follow the strategy outlined above and make bzr the best
available frontend for GitHub.

Good luck!

Sincere regards,

P.S.  Why do I care, if I love git so much?  Because my support for
open source is not about me, it's about the users, all of them.  And
here's a market segment that git doesn't serve very well.

Footnotes: 
[1]  The Python project's way of saying "not in this century".

[2]  Well, it could be "all" at the expense of a .bzrdata as a sibling
to .git, but that's kind of inelegant.  A useful hack for the proof of
concept stage, though.

[3]  Not saying it wasn't worth it, but the resources are no longer
available.  Concentrate on a few main ideas.  Format-fiddling isn't
worth it, with the exception described below.

[4]  An alternative approach would be empty tree objects.  But those
would also have to be stripped for compatibility with a "real" git
repo.

[5]  Go, Nippon!  Too bad about the embarrassing Scotland match, but
the South Africa match was a great one!  For Japan, anyway.