[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: joakim
Subject: Re: On the subject of Git, Bazaar, and the future of Emacs development
Date: Thu, 28 Mar 2013 08:53:01 +0100
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux)

Richard Stallman <address@hidden> writes:

>     I am surprised no one has mentioned in this thread the parade of
>     erstwhile bzr developers (including Martin Pool) who have admitted on
>     the bzr mailing list that they have abandoned the project and why.
> 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.htmlbefore.  
> It says many useful things but does not say anything about
> the crucial question: whether Bzr is maintained enough or not.

Isn't it a reasonable position that the users of bzr have say in wether
bzr is sufficiently maintained or not?

I have done my best to be a constructive user of the tool, and I have
had many technical difficulties. When I try to find solutions to the
issues I notice the following:

- The bzr community is very helpful. This is good.

- There are many well known bugs. There are also many well known patches
  for these, some of them provided by Emacs developers. They never enter
  upstream. By "never" I mean years. This is bad.

The situation generates a lot of frustration.

Anyway, from here one can discuss solutions. I think most of them have
been discussed more than once. Heres my take:

- Accept losses with bzr. Life goes on.
- Use Git as a technical interim solution.
- Incrementally produce a GNU-Git, which is maintained by GNU
The initial versions of this new implementaiton could use libgit2, which
is LGPLV2. Eventually the library could be rewritten as GPLV3 if deemed
necessary. (OTOH using libgit2 doesnt seem worse than using Python as
bzr does), The new implementation could also use Guile, which would
support an important GNU project. 

So, thats IMHO a reasonable idea. I only have very small resources to
devote personally towards it though.

Joakim Verona

reply via email to

[Prev in Thread] Current Thread [Next in Thread]