How can we ensure Bazaar (bzr) remains active?

[Kevin Carrasco]

These are all valid points. :-(

There's not enough incentive to use a system which is not popular, not 
well supported, and appears to have no future. And, it's own users don't 
appear to have much faith in it.

Like it or not, I'll have to use Git more; however, this will be 
combined with using Hg also.

Thanks:
Kevin C.

On 09/23/2015 11:33 PM, Stephen J. Turnbull wrote:
> 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.
>