
Bzr is dying; Emacs needs to move - __david__
https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00005.html
======
hyperpape
I went back and looked at the older discussion, and it doesn't paint Stallman
very well as the head of a project. He pins the question of whether to keep
using bzr not on whether it is good or whether the Emacs developers want it,
but on whether it's being "maintained".

But then he seems to define maintenance as having fixed a specific bug that's
been around for over a year, blocking a point release.

He admits that he can't follow the developers list to see if they're genuinely
doing active maintenance (reasonable enough: he has a lot on his plate), but
also won't accept the testimony of Emacs developers that the mailing list is
dead and there's no evidence of real maintenance.

When questioned, he says that there's too much at stake to abandon bzr if it
can be avoided at all. But the proposed replacement is GPL software. This is
just madness.

Refs: [http://lists.gnu.org/archive/html/emacs-
devel/2013-03/msg009...](http://lists.gnu.org/archive/html/emacs-
devel/2013-03/msg00906.html).

[http://lists.gnu.org/archive/html/emacs-
devel/2013-03/msg008...](http://lists.gnu.org/archive/html/emacs-
devel/2013-03/msg00870.html)

(and surrounding posts).

~~~
blumentopf
> it doesn't paint Stallman very well as the head of a project

Is this news to you?

Cf. e.g.
[http://www.jwz.org/doc/lemacs.html](http://www.jwz.org/doc/lemacs.html)

~~~
vezzy-fnord
Not to mention his insistence on GNU Hurd being based on Mach, which pretty
much ended up killing the project.

~~~
IgorPartola
That's a simplistic view. First, the GNU project is very much alive: the GNU
tools are used in a huge number of operating systems and are installed on a
staggering number of devices. I would bet that the system you are writing this
comment from is running thanks to the GNU software.

Second, it is debatable whether sticking to Hurd was a good or a bad idea
_technically_. Imagine if Stallman and co. managed to convince a good number
of developers that it was a good idea and the kernel was competitive with
Linux, BSD's, etc. If you believe you have a technically superior vision for
your product, should you compromise on it just because people who do not share
in your vision will not join you?

In the end, I think what killed the pure GNU/Hurd OS was bad PR and
absolutism. Hurd as a technical question was just a small part of that.
Remember, the debate between the Free and the Open Source guys was pretty
fierce. Today we use terms like FOSS to describe all open software, but when
Linux and Hurd were young these were different camps with opposing
philosophies, and the one that appealed to more developers won out. In
simplistic terms, you can think of this as the VHS vs Betamax debate. Can you
blame the Betamax backers for continuing to try to push it and "killing" it as
a result?

~~~
Sssnake
>the GNU tools are used in a huge number of operating systems

You mean linux? That isn't a huge number.

>and are installed on a staggering number of devices

The staggering number of devices you refer to almost exclusively run busybox
or one of the similar projects. GNU software is hugely bloated and not a good
choice for embedded systems.

>Second, it is debatable whether sticking to Hurd was a good or a bad idea
technically

No, it was fine technically. It had no developers and so nothing happened.
Minix exists, obviously microkernels are possible.

~~~
josephlord
GNU tools were often used on other OSes too including Solaris and other
commercial Unixes but also Windows under Cygwin. Particularly GCC, make etc.
but also command line tools such as grep where the default platform versions
were often not as feature rich. I didn't use those platforms so others will
remember and know better but I don't think huge was an obviously wrong
description.

~~~
Sssnake
There is a big difference between "some people optionally could install GNU
stuff in addition to their existing tools" and "those OSes use GNU tools".

~~~
josephlord
>the GNU tools are used in a huge number of operating systems

Fair enough, I read "in" as a synonym for "on" but read in a less casual way
the difference could be important.

Even in the "in" case I think many BSD's used GCC as the default compiler
(CLANG seems to be taking over now).

------
mikro2nd
>git won the mindshare war. I regret this - I would have preferred Mercurial,
but it too is not looking real healthy these days

I confess that my perception of Mercurial is the diametric opposite of the
author's. Recently I believe I have seen a modest resurgence of interest in Hg
and increased uptake. Am I just seeing this through some peculiar VCS-warped
glasses?

I believe that much of the popularity of git stems from github making it very
easy to adopt, something that bitbucket doesn't seem to have pulled off as
well.

~~~
binarycrusader
Yep, I don't understand the author's assertions about Mercurial either.

Mercurial remains a better choice for a few use cases where git simply falls
flat.

Among game developers, in particular, because of their need to have revision
control for large assets, Mercurial seems to be more popular than git due to
the large files extension.

And realistically, perforce or other solutions appear to be even more popular
among that particular developer segment.

Personally, I use Mercurial wherever possible, but that's not because I
believe Mercurial to be technically superior, it's just because I hate git's
UI.

Perhaps among the general FOSS community git is more popular, but both git and
Mercurial have yet to met the needs of many developers.

~~~
bitwize
_Among game developers, in particular, because of their need to have revision
control for large assets, Mercurial seems to be more popular than git due to
the large files extension._

Most game devs -- I'd say even most devs in grown-up, professional shops --
use p4.

~~~
binarycrusader

      Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4.
    

Hence why I said "realistically, perforce or other solutions appear to be even
more popular among that particular developer segment." My comment you quoted
was comparing the popularity of Mercurial to Git, not p4.

Also, I'd disagree with your assertion regarding "most devs in grown-up,
professional shops". Microsoft's SourceSafe has a large following among the
corporate world. And many of the largest tech companies I'm aware of don't use
p4 primarily; they use git, mercurial, svn, cvs, SourceSafe, home-grown
solutions, etc.

~~~
voltagex_
Are that many people really using SourceSafe still? TFS is now Microsoft's
preferred solution, although I don't know what they use internally.

~~~
taspeotis
Disclaimer: I'm not a Microsoftie, just collecting some links and adding my
own opinion.

Microsoft use TFS heavily [1].

Right now I imagine most MS projects are TFS but it doesn't appear to be
mandated. Maybe for the big, internal-only stuff. ASP.NET is hosted on
CodePlex as a Git repo [2] and MEF is Hg [3].

They've just added Git support to TFS and that probably means a lot of MS
projects will migrate to Git over time.

[1]
[http://blogs.msdn.com/b/visualstudioalm/archive/2013/08/20/t...](http://blogs.msdn.com/b/visualstudioalm/archive/2013/08/20/tfs-
internal-usage-statistics-1st-half-cy-2013.aspx)

[2] [http://aspnetwebstack.codeplex.com/](http://aspnetwebstack.codeplex.com/)

[3]
[https://mef.codeplex.com/SourceControl/latest#.hgignore](https://mef.codeplex.com/SourceControl/latest#.hgignore)

------
stiff
FWIW, just a few days ago I was browsing through the Emacs Bzr repository -
after a full bzr clone, that took ridiculously long as well, a simple bzr
blame takes 40-60 seconds to execute locally, and I have an SSD drive, four-
core intel i7 and 8GB of RAM. I have never seen this kind of slowness with
Git, with any repository size.

~~~
mathattack
Does this make the issue a critique of RMS's management style, or of the FSF
licensing that is unable to back out of a failed project?

~~~
justincormack
If you look at the thread, it seems to be neither, just inertia. The licensing
is fine, its GPL, no different from bzr.

~~~
drzaiusapelord
Inertia seems to fit with bad management style. Good managers should be
fighting it when it becomes cumbersome. Stop making excuses for FOSS
celebrities and start demanding better outcomes.

------
hyperpape
Well, it looks like it will happen.[1]

In light of my other comment, good for Stallman. Seems he wasn't actually so
hardheaded as it seemed.

[1] [https://lists.gnu.org/archive/html/emacs-
devel/2014-01/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2014-01/msg00014.html)

------
mickeyp
The important take-away here isn't the relative merits of each DVCS, but that
bzr is not used by anybody any more, and it is impeding the uptake of new
contributors to Emacs.

~~~
rbanffy
Compared to the decision (and ability) to contribute to Emacs, the choice of
DVCS seems to be rather unimportant.

~~~
aaronem
The impression I have is that bzr is just another roadblock between a
potentially interested novice and a patch accepted into the Emacs source.

(It's not by far the largest one, though, and while I think esr has a point, I
also think it'd be of help for some of the current Emacs developers to publish
a "How to start hacking Emacs" document, for the benefit of people like me who
would love to contribute but who have _absolutely no idea where or how to
start_.)

~~~
quotemstr
> help for some of the current Emacs developers to publish a "How to start
> hacking Emacs" documen

1\. Find thing you don't like 2\. M-x find-function RET function-to-fix RET
3\. Hack hack hack (use C-M-x or M-x eval-buffer liberally; also, read about
edebug) 4\. Make diff relative to Emacs base code 5\. Send diff to bug-gnu-
emacs@gnu.org

What I love about hacking on Emacs is that it's so easy to find the bit of
code responsible for a given feature and hack on that code in a running
editor. There's nothing like it. If I'm using Firefox and don't like the
address bar, I need to go dig through XUL, find the thing I don't like, and
restart Firefox. Emacs? You just find the function and edit it right in the
editor.

~~~
aaronem
Thank you, yes, it's not so much finding the code I need to modify that's the
problem, as understanding how any given single thing fits into the Emacs C
source as a whole. Hacking the Lisp side I don't really have a problem with --
but if I want to, for example, extend the MESSAGE primitive so that it can
check a list of messages not to emit in the minibuffer, things get very hairy,
very fast. A general overview of what's what, and where, in the C source,
would be extremely useful, and I haven't had much luck finding anything like
that in the source distribution or online. (And, yes, I have read
etc/CONTRIBUTE, etc/DEBUG, and (Info)Elisp/GNU Emacs Internals/*. And I'm
pretty sure doing what I'm talking about doing to MESSAGE would be a bad idea,
because it'd require a call up into Lisp space every time the primitive gets
called, which can be extremely frequent especially during initialization. But
I know somebody who'd like to have that functionality available, and it seemed
like a relatively simple place to start, until I tried actually doing it.)

------
TacticalCoder
Many Emacs contributors are already using Git and simply publishing everything
in Github. Most of the things in my .emacs comes from Github. Simply they're
not part of the core Emacs.

I think the issue is not only bzr vs Git. It's also, if I understand things
correctly, the super restrictive license that the core Emacs has, making every
developer sign papers and send them (by snailmail!? or are scans allowed!?)...
And if you several other contributors helping you, you must have them all sign
these papers.

I've seen at least one prolific .el Emacs author (I think the mulled/multi-
line-edit author) complain about that: saying that out of 10 people who helped
him he managed to have nine of them sign the papers and sent them to him and
couldn't contact the last one...

And eventually he simply decided to abandon getting all the signatures and
went it's own way (i.e. Github / non-core Emacs, like many do).

I'm not well versed in licenses / GPL things but I'm a long time Emacs users
and I'm definitely seeing change: now most of the newer (and great) .el files
I add to my Emacs are coming from Github.

------
davidw
The Tcl guys are in a similar situation - they use Fossil. Which by all
accounts looks pretty cool, but at this point it's "not git".

[http://www.fossil-
scm.org/index.html/doc/tip/www/index.wiki](http://www.fossil-
scm.org/index.html/doc/tip/www/index.wiki)

~~~
sigzero
If Tcl Core wanted to move to git, Fossil exports repos to that format. So
they really lost nothing. They have a small team of commiters as well so
Fossil works just fine for them.

~~~
mjs
Well, there's also the "social and signaling effects" of using something
that's non-git, that Eric S. Raymond articulates well: "we cannot afford to
make or adhere to choices that further cast the project as crusty, insular,
and backward-looking."

~~~
stcredzero
_Well, there 's also the "social and signaling effects" of using something
that's non-git_

The "not a field" of Computer Programming, to appropriate Alan Kay's quip, is
so broken that "social and signaling effects" swamp actual facts and
information to a degree that makes it look like Astrology. I've been watching
this for decades now -- literally.

Dynamic languages were for years after still tarred with being "slow" when
both Moore's Law and progress in JIT VMs and generational GC had make them
perfectly fine for tons of applications. If the half-life of patently false
misinformation is literally about a decade, and what passes as fact between
practitioners is less fact than school rumors, what does that say about our
"field?"

~~~
davidw
What are the actual facts in this case?

There are tons of people who use and know git. It's fast, it works pretty
well. There's some value in the fact that it's widely known and used (network
effects), probably enough that whatever takes its place will probably be not
just a bit better, but a lot better, in some way. bzr does not strike me,
offhand, as being a lot better. Is fossil?

So in this case, I think that the network effects are an important fact.

~~~
stcredzero
_What are the actual facts in this case?_

I'm talking in general. I think it's good they're going to git.

 _bzr does not strike me, offhand, as being a lot better._

I never said it was better or worse. My comment is about the "field" and how
accurate its "information" is in general. Sometimes social signalling and
network effects are good. What disturbs me is that _so many of us use this as
a substitute for facts and objective analysis._

Taking social signalling and network effects into account is okay. Only going
that far and stopping is just dim laziness. (It's also behind the worst
examples of sexism and ageism in our "field.")

~~~
wonderzombie
> What disturbs me is that so many of us use this as a substitute for facts
> and objective analysis.

I think there's something to this. At a guess, people use a heuristic because
facts and objective analysis are hard. I don't mean that sarcastically— I mean
that it's difficult and complex even if you are not lazy. When people opt for
what everyone else is using, they receive the benefits of treading a well-worn
path. This isn't an excuse, but I am sympathetic. Some people are just trying
to get work done.

On the other hand, that is a poor justification for being too lazy to do the
job right. Often a problem isn't as hard or complex as it looks, and you might
just learn something while looking into it. You get the idea.

Also, +1 to your comment re: sexism and ageism.

------
popey
"most of Canonical's in-house projects have abandoned bzr for git".

Nope. Unity, Mir, Upstart, all of the new phone/tablet apps and platform tools
are on bzr on launchpad.

Not disputing the fact that git has won the war, just nitpicking that point.

------
pcx
Here is a previous discussion on emacs-devel from Mar'13
[http://lists.gnu.org/archive/html/emacs-
devel/2013-03/thread...](http://lists.gnu.org/archive/html/emacs-
devel/2013-03/threads.html#00870)

Stallman's opinion on this subject - [http://lists.gnu.org/archive/html/emacs-
devel/2013-03/msg009...](http://lists.gnu.org/archive/html/emacs-
devel/2013-03/msg00905.html)

TLDR Stallman doesn't want Emacs to give up on bzr (also a GNU project) yet.
This opinion might change now though.

~~~
thearn4
Just read the link to Stallman's opinion - side question: he signs his name
with a Dr. prefix. But did he finish graduate school at MIT?

~~~
Someone
According to
[http://en.wikipedia.org/wiki/Richard_Stallman](http://en.wikipedia.org/wiki/Richard_Stallman),
he has 14 honorary doctorates and professorships.

~~~
leoc
It's considered seriously naff to title yourself Dr. on the strength of an
honorary doctorate, though — at the very least, you should add " _honoris
causa_ ". (Even with an earned doctorate you're supposed to avoid referring to
yourself as Dr. Smith, in the same way that you shouldn't introduce yourself
as Mr. or Mrs. Smith.) Not that I'd really grudge the title to RMS though,
who's done more technical hard work and innovation than many people who are
running around with earned PhDs.

------
djm_
For those wondering: Vim is currently on Mercurial @ Google Code [1]

[1] [http://www.vim.org/sources.php](http://www.vim.org/sources.php)

~~~
guns
And happily for git users, the git-hg plugin makes maintaining a git mirror of
the vim hg repo very convenient:

[https://github.com/cosmin/git-hg](https://github.com/cosmin/git-hg)

Submitting patches upstream is also not a problem as Bram Moolenaar only
accepts patch files on the dev mailing list.

------
Aqwis
Oddly, both Bazaar, Git and Mercurial were created around March/April 2005.
Why the sudden appearance of popular DVCSs around that time, and why did
Bazaar fall behind the other two in popularity?

~~~
gizmogwai
All of them emerged due to the end of license agreement for a free license of
bitkeeper for the linux kernel. Git won due mainly to Linus personnality and
the rise of "social coding" via github. Bazaar failed because, at the
beginning, it was painfully slow compare to git and mercurial. It speed has
increase over time, but bad reputation is hard to get rid of.

~~~
alok-g
>> Bazaar failed because, at the beginning, it was painfully slow compare to
git and mercurial. It speed has increase over time, but bad reputation is hard
to get rid of.

Is this an example that goes against the common advice to launch an MVP fast
to test the market (and then keep on improving)? It seems that the advice is
valid only when there is nothing for the customer to compare the to-be-
launched product to. If competing products end up launching at around the same
time as yours, the advice may turn its head on you.

~~~
jeltz
Git was also early to the market, but had a fast core and terrible user
interface. Git was used for the Linux kernel only two months after Linus had
started coding.

------
sixtypoundhound
Bzr certainly isn't dead.

git has won the mindshare war for mainstream developers, but I've found it to
be a useful FOSS alternative for developers forced to use a Windows
environment [for business-related reasons, don't laugh..it pays the bills].
Their UI is a bit more intuitive than git's for new users.

Now, if you're a hardcore Linux-stack career dev...get onto git ASAP... but
for lesser folks...bzr works just fine...

~~~
Macha
> but I've found it to be a useful FOSS alternative for developers forced to
> use a Windows environment [for business-related reasons, don't laugh..it
> pays the bills]. Their UI is a bit more intuitive than git's for new users.

However, the same also applies to Mercurial, and even though Mercurial is less
popular than Git, it still has a lot more devs who use it than Bzr.

------
harel
I'm using bzr on a large scale project and have not experienced any problems.
A full fresh branch does take a while to complete but I find it acceptable as
we're not branching the full repo from the server that often. Usually its
local branches. When using git on a similar scale project we found that we
spent a lot more time managing the source control system than we ought to.
Source control should be something you rarely worry about and requires no
'management' other then regular usage. Git was not that. Git required effort.

------
manish_gill
I had to interact with bzr last year for my GSoC project (Mailman, hosted on
Launchpad). It wasn't a pleasant experience, and got a whole lot more
complicated when I had to move a Git repo to LP.

Bazaar is bad. :(

------
dscrd
Yeah, Mercurial is a viable choice still for just about all projects, and most
of the time the simpler one.

------
rjzzleep
the most annoying thing about bzr in my opinion is it's stupid branching
model. luckily a migration to git is a oneliner.

git init ; bzr fast-export --plain | git fast-import

~~~
icebraining
_luckily a migration to git is a oneliner._

I wish. Unfortunately, not all repos we use are owned by us, and using two
VCSs is worse than sticking with bzr.

~~~
sergiosgc
Isn't it possible to track the upstream just like with svn? We use git
internally but interact with third party subversion repositories. We do it by
dedicating a branch to tracking the svn repo, use git-svn to branch and to
push the commits (after rebasing). It's not perfect but after a few hurdles at
the beginning it is now problem free.

------
midas007
Duplicate of
[https://news.ycombinator.com/item?id=6999094](https://news.ycombinator.com/item?id=6999094)

~~~
ableal
Curiously, the URL seems exactly identical in both submissions, which are
almost consecutive ( ...94, ...96).

That probably means the duplicate detector has some delay on getting its past
submissions data. The rate of submissions these days seems to average one a
minute, but the delta on this pair may be different, and it is not apparent by
now.

~~~
__david__
I can't tell now that the other one is dead, but I believe it's link was http:
while this one's is https:. I use the "https everywhere" browser extension so
when I copied the URL I probably got the upgraded one. I think that explains
why the dup detector didn't catch it. I don't know why this story took off and
the other died. Maybe the headline?

~~~
ableal
You're probably right, I only looked at the path.

Thanks for the followup.

~~~
midas007
TLS FTW. (or sometimes TLS MITM FTW.)

------
codex
The entire GNU project is like a house that looked so mod in 1971, but now has
peeling paint, stained concrete, shag carpeting that smells pretty funky, and
a crazy old relative that haunts the place. "Renovation" is changing the light
bulbs and occasionally washing the stucco.

------
rmrfrmrf
It's a bummer to think of all of the real-life dollars that have been sunk
into Bzr's development, which I'm sure makes a decision like this harder. That
said, isn't this what forking is for? The people who want Git support should
code and maintain it themselves.

------
kro0ub
For those who want to learn BZR and help revive it by adopting it in your
projects, there's a nice book here: [http://www.foxebook.net/bazaar-version-
control/](http://www.foxebook.net/bazaar-version-control/)

------
tenfingers
I wished people would use software based on merits, not on popularity. That
being said, Bzr is slow, it was always slow from day 1 -- and slowness is part
of the UI experience.

~~~
rlpb
Popularity means developers, which means bugfixes and more features in the
future which projects may want to use. Switching DVCS has a cost to a project.
Thus software popularity is important.

This may be unfortunate, but this is how it is. DVCSs are by no means complete
today, and cross-pollination of features continues. An unpopular project that
has fewer developers working on it will fall behind. A project that doesn't
want to keep switching DVCS has a reasonable interest in the DVCS project's
future, since future features will come "for free".

------
Beliavsky
Do people really decide whether to contribute to an open source project based
on the version control system it uses, rather than the importance of the
project itself?

------
codex
If Emacs moves to git, can we call it by its proper name: git/Emacs?

------
crncosta
"git won the mindshare war"

Sad, but true...

~~~
mateuszf
What's so sad about it? IMHO git is awesome.

~~~
midas007
I only use git:

\- it has a lot of non-orthogonalities and non-closure operations (ie options
on one command are different or not present on other commands)

\- if the network drops, fetches and pushes have to start from scratch. For
fetches, it would be nice to save partial packs and resume them. For pushes
over crappy links, doing similar could be a potential DDoS, so setting up some
sort of rsync box is probably better.

------
bachback
wow.

please, please, you Emacs/LISP gurus out there: make a working modern package
manager and integrate the browser like lighttable does. and perhaps rewrite
emacs from scratch so that the source code makes sense in today's world not in
1980's world.

unfortunately lighttable is staying closed for much too long, but something
like it is desperately needed.

~~~
swah
I agree - Emacs has to be rewritten on top of a modern rendering engine!

~~~
saalweachter
They did. It is called 'Eclipse'.

~~~
sixthloginorso
Just not the same. Adding functionality to Eclipse is a "project". In Emacs,
it's just some code and an eval-last-sexp away.

