Re: On the subject of Git, Bazaar, and the future of Emacs development

[Karl Fogel]

Richard Stallman <address@hidden> writes:
>I know that Martin Pool no longer works on Bzr.  He never told me why,
>but I think that Canonical decided to stop funding its development
>very much.
>
>I don't have time to read the Bzr mailing list.  Or any development
>mailing list.  The only such list I am on is this one, and the only
>reason I can be on this ls is that I don't follow most of the questions
>that come up.  You might as well tell me to fly to the moon as tell
>me to read something on the Bzr list.
>
>I read http://stationary-traveller.eu/pages/bzr-a-retrospective.html
>before.  It says many useful things but does not say anything about
>the crucial question: whether Bzr is maintained enough or not.

And later:
>
>    The answer to that question should be obvious by looking at the
>    public repository and developers' list.
>
>I can't do that -- it is too big a job.  I have to find out in ways
>that take less time.  I am working more than 10 hours a day.

Well, really, you don't have time to pay close enough attention to Bzr
development to competently decide whether it's still a good choice for
Emacs.  That's fine -- no one has time to do every important thing, and
you do many other important things.

But then why do you think you still have the time & mental bandwidth to
make this decision well?  Why not delegate it to the Emacs maintainers
on the grounds that you no longer have time to do a good job of this
evaluation?  You delegate other things.  Why is this special?

You wrote:

>I hope you understand that before I take the drastic step of giving up
>on a package, I need to be convinced there is no hope.  People on this
>list are proposing that I give up after a snap judgment based on a
>weaker criterion.  I won't do that.  The advice which suggests I do that
>is not useful or relevant.

The idea that asking one person about one bug will answer the question
"Is Bzr maintained enough?" is wrong.  Even if someone responds and
fixes that one bug, that does not mean there is hope.  To correctly
assess the chances of hope, you have to look at the overall situation --
which others here have already done, in greater depth and taking more
variables into account than you can.  Many people in this thread,
including myself, have already done a more thorough investigation into
the question than you are able to do, given your time constraints, and
most have come to the same conclusion.

>The help that I need, to make the decision, is to give me the
>corrdinates of the specific Bzr bug report about the ELPA branch.
>There should be someone on this list for whom that would be quick and
>easy.

https://bugs.launchpad.net/bzr/+bug/830947, as Eli pointed out later in
the thread.

The most recent comment on that bug is from November of last year.  In
https://code.launchpad.net/~rrw/bzr/830947-tree-root-exception there is
a patch (not landed in mainline; there is no estimate of whether the
patch is ready to land in mainline, nor when it would happen if so).
Bug 937101 also gives a workaround recipe in comment #11.

But this one-bug approach is a bad way to evaluate overall project
health.  A single bug is not a proxy for project health.  A collection
of data points is.  If you don't have time to evaluate that collection,
and don't have time to trust those who have done so, then your chances
of making a good decision are essentially random.

-Karl