John Wiegley | 26 Mar 20:38 2013

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

Hello all,

We have often debated the merits of Git vs. Bazaar, and which one the GNU
project should use for Emacs development.  I think now is an appropriate time
to revisit this decision.

My main reason for bringing this up again is that Bazaar development has
effectively stalled.  There are major bugs which have been in their
bug-tracker for years now -- bugs affecting Emacs development, such as the
ELPA repository -- whach have been ignored all this time.  There are also
other factors, but this one alone is significant enough that I think it
justifies us switching over to Git all by itself.

So, to Richard as the undisputed Czar of all things Emacs: can we now, pretty
please, switch to Git? :)  I'm happy to coordinate whatever resources it takes
to make a full and faithful conversion from Bzr happen as soon as possible.

Yours,
  John Wiegley

Jordi Gutiérrez Hermoso | 26 Mar 20:42 2013

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

On 26 March 2013 15:38, John Wiegley <johnw <at> newartisans.com> wrote:
> My main reason for bringing this up again is that Bazaar development has
> effectively stalled.  There are major bugs which have been in their
> bug-tracker for years now -- bugs affecting Emacs development, such as the
> ELPA repository -- whach have been ignored all this time.

Let us also note that the ELPA repository is now in git due to this,
so part of Emacs development is already de jure in git, and lots of
other development is de facto done on git.

I still think git is a horrible DVCS, but at least it's maintained, unlike bzr.

- Jordi G. H.

Stefan Monnier | 27 Mar 02:32 2013
Picon

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

> Let us also note that the ELPA repository is now in git due to this,

Actually, no, it's not using Git yet.  But any help I can get to do that
would be welcome.

        Stefan

Barry Warsaw | 2 Apr 02:31 2013

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

On Mar 26, 2013, at 03:42 PM, Jordi Gutiérrez Hermoso wrote:

>I still think git is a horrible DVCS

I happen to agree.  Mercurial is much better, though I still prefer Bazaar.
Mercurial is also GPLv2 and has free (as in $) hosting facilities available.

FWIW, I tend to think that people like git because of github more than because
of git in particular.  Unfortunately github is not free software AFAIK.
Neither is Bitbucket (probably the most popular hosting site for Mercurial
branches).  OTOH, Launchpad (the most popular bzr hosting site) *is* free
software too.

Cheers,
-Barry
Timur Aydin | 2 Apr 10:56 2013

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

On 4/2/2013 3:31 AM, Barry Warsaw wrote:
> FWIW, I tend to think that people like git because of github more than because
> of git in particular.

I think the overwhelming reason that people like git is that it is very 
fast with very large repositories. I am developing on uClinux with a 
close to 2GBytes repository. With big repository sizes, git is really 
the only option by a very large margin ...

--

-- 
Timur Aydin

Teemu Likonen | 2 Apr 15:30 2013
Picon
Picon

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

Timur Aydin [2013-04-02 11:56:25 +0300] wrote:

> On 4/2/2013 3:31 AM, Barry Warsaw wrote:
>> FWIW, I tend to think that people like git because of github more
>> than because of git in particular.
>
> I think the overwhelming reason that people like git is that it is
> very fast with very large repositories.

I think Git is liked so much because it gives a lot of power to user.
There was this time when the "Git opposition" had some/many
philosophical reason why a DVCS software shouldn't allow user do various
things. From certain point of view they can be right but users chose Git
anyway because it has the functionality that they want.
Eli Zaretskii | 2 Apr 18:38 2013
Picon

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

> From: Teemu Likonen <tlikonen <at> iki.fi>
> Date: Tue, 02 Apr 2013 16:30:34 +0300
> Cc: emacs-devel <at> gnu.org
> 
> I think Git is liked so much because it gives a lot of power to user.
> There was this time when the "Git opposition" had some/many
> philosophical reason why a DVCS software shouldn't allow user do various
> things. From certain point of view they can be right but users chose Git
> anyway because it has the functionality that they want.

If it were that simple, Emacs would have been much more popular editor
than it is now.  Yet, somehow that didn't quite happen.  Perhaps "a
lot of power" is not the single most important reason, after all.

Teemu Likonen | 2 Apr 19:02 2013
Picon
Picon

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

Eli Zaretskii [2013-04-02 19:38:26 +0300] wrote:

> From: Teemu Likonen <tlikonen <at> iki.fi>
>> I think Git is liked so much because it gives a lot of power to user.
>> There was this time when the "Git opposition" had some/many
>> philosophical reason why a DVCS software shouldn't allow user do
>> various things. From certain point of view they can be right but
>> users chose Git anyway because it has the functionality that they
>> want.
>
> If it were that simple, Emacs would have been much more popular editor
> than it is now. Yet, somehow that didn't quite happen. Perhaps "a lot
> of power" is not the single most important reason, after all.

Yes, and the other in my message was "the functionality that they
[users] want." Meaning features that matter.

In his retrospective Velmer Vernooij said:

    We lost sight of what mattered for our users, focusing on features
    that were nice but perhaps not as necessary as we thought. We
    overengineered. We didn't get rid of the crufty unnecessary
    features. It's harder to comprehend, contribute to or fix
    performance issues in a large layered codebase. And the larger a
    codebase becomes, the larger the surface for bugs, the harder it is
    to refactor.

http://stationary-traveller.eu/pages/bzr-a-retrospective.html
Eli Zaretskii | 2 Apr 19:24 2013
Picon

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

> From: Teemu Likonen <tlikonen <at> iki.fi>
> Cc: ta <at> taydin.org, emacs-devel <at> gnu.org
> Date: Tue, 02 Apr 2013 20:02:20 +0300
> 
> Eli Zaretskii [2013-04-02 19:38:26 +0300] wrote:
> 
> > From: Teemu Likonen <tlikonen <at> iki.fi>
> >> I think Git is liked so much because it gives a lot of power to user.
> >> There was this time when the "Git opposition" had some/many
> >> philosophical reason why a DVCS software shouldn't allow user do
> >> various things. From certain point of view they can be right but
> >> users chose Git anyway because it has the functionality that they
> >> want.
> >
> > If it were that simple, Emacs would have been much more popular editor
> > than it is now. Yet, somehow that didn't quite happen. Perhaps "a lot
> > of power" is not the single most important reason, after all.
> 
> Yes, and the other in my message was "the functionality that they
> [users] want." Meaning features that matter.

So you are saying Emacs doesn't have "the functionality that they
[users] want"?

> In his retrospective Velmer Vernooij said:
> 
>     We lost sight of what mattered for our users, focusing on features
>     that were nice but perhaps not as necessary as we thought. We
>     overengineered. We didn't get rid of the crufty unnecessary
>     features. It's harder to comprehend, contribute to or fix
(Continue reading)

Teemu Likonen | 2 Apr 19:44 2013
Picon
Picon

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

Eli Zaretskii [2013-04-02 20:24:40 +0300] wrote:

> From: Teemu Likonen <tlikonen <at> iki.fi>
>> Yes, and the other in my message was "the functionality that they
>> [users] want." Meaning features that matter.
>
> So you are saying Emacs doesn't have "the functionality that they
> [users] want"?

Yes. But this is about masses. Emacs has a lot of power but that power
does not matter to most people (I believe). They don't need the power.
Surely Emacs's power matters to me. Thank you all!

So, in my opinion Git has just the kind of power that matter to
potential DVCS users and that's why it got popular. It's just my
reasoning, though.

It's probably so that people who like Git tend to explain that it got
popular because the software is good. On the other hand people who don't
like Git tend to explain that it's not about Git's quality but rather a
network effect and general coolness aspect of the choice (Hey, Torvalds
uses it!!!!!!). That's how we humans explain things. Good things are
popular because of reasons worth having. Bad things are popular because
of worthless reasons.
Eli Zaretskii | 2 Apr 18:36 2013
Picon

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

> Date: Tue, 02 Apr 2013 11:56:25 +0300
> From: Timur Aydin <ta <at> taydin.org>
> 
> On 4/2/2013 3:31 AM, Barry Warsaw wrote:
> > FWIW, I tend to think that people like git because of github more than because
> > of git in particular.
> 
> I think the overwhelming reason that people like git is that it is very 
> fast with very large repositories. I am developing on uClinux with a 
> close to 2GBytes repository. With big repository sizes, git is really 
> the only option by a very large margin ...

Not sure what you are saying.  The Emacs repo is about the same size,
circa 1 GB (not counting the working tree), in both bzr and git, and
they both handle this size well.  Are you saying that Emacs is
"small"?

Xue Fuqiao | 2 Apr 15:19 2013
Picon

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

On Mon, 1 Apr 2013 20:31:40 -0400
Barry Warsaw <barry <at> python.org> wrote:

> Mercurial is also GPLv2

Mercurial is licensed under GPL version 2 or any later version
("GPLv2+")[1].

> OTOH, Launchpad (the most popular bzr hosting site) *is* free software
> too.

That's true.  BTW Savane is also a free hosting system.  It powers free
software development platforms such as Gna! and Savannah.  It also
integrates functionalities as well as different external applications
installed in the system running Savane
(Mailman/Git/Bazaar/Mercurial/Subversion/CVS/Subversion/Arch...).

[1] http://selenic.com/hg/file/tip/COPYING

--

-- 
Xue Fuqiao
http://www.gnu.org/software/emacs/

Alan Mackenzie | 2 Apr 16:54 2013
Picon

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

Hi, Barry.

On Mon, Apr 01, 2013 at 08:31:40PM -0400, Barry Warsaw wrote:
> On Mar 26, 2013, at 03:42 PM, Jordi Gutiérrez Hermoso wrote:

> >I still think git is a horrible DVCS

> I happen to agree.  Mercurial is much better, though I still prefer Bazaar.
> Mercurial is also GPLv2 and has free (as in $) hosting facilities available.

One aspect not yet touched upon is documentation.  Compare, for example,
{git,hg,bzr} help merge.  git dumps you into a ~300 line man page.  hg
outputs a concise, yet complete ~40-line summary.  bzr outputs a rambling
~100 line essay which might say what the command does, but it's difficult
to tell.

hg wins here hands down.  Given how many commands there are in git,
having to study multi-hundred line man pages here seems suboptimal.
Indeed, having to learn git could be a barrier to participation in
projects which use it.

> Cheers,
> -Barry

--

-- 
Alan Mackenzie (Nuremberg, Germany).

Teemu Likonen | 2 Apr 17:13 2013
Picon
Picon

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

Alan Mackenzie [2013-04-02 14:54:57 +0000] wrote:

> hg wins here hands down. Given how many commands there are in git,
> having to study multi-hundred line man pages here seems suboptimal.
> Indeed, having to learn git could be a barrier to participation in
> projects which use it.

There have been ideas why Git is inferior to its competitors. Yet it
became the leader. The masses chose it anyway. So actually I think the
opposite is true: it's a barrier if project does not use Git (the market
leader).

And few people study multi-hundred-line man pages because it's not
necessary. Yet the features and information are documented there in the
manuals, when one needs.
Barry Warsaw | 2 Apr 17:45 2013

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

On Apr 02, 2013, at 06:13 PM, Teemu Likonen wrote:

>There have been ideas why Git is inferior to its competitors. Yet it
>became the leader.

Network effects are powerful, but don't always lead to the best choice.  OTOH,
I still suspect that dvcs adoption is miles behind traditional vcses such as
Subversion.

-Barry
Teemu Likonen | 2 Apr 18:21 2013
Picon
Picon

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

Barry Warsaw [2013-04-02 11:45:08 -0400] wrote:

> On Apr 02, 2013, at 06:13 PM, Teemu Likonen wrote:
>> There have been ideas why Git is inferior to its competitors. Yet it
>> became the leader.
>
> Network effects are powerful, but don't always lead to the best
> choice.

True, I guess. But many large projects use Git and I believe they are
competent programmers and people who know what they want. Do you think
that Git is wrong tool for many people who are using it now?

> OTOH, I still suspect that dvcs adoption is miles behind traditional
> vcses such as Subversion.

Maybe, but among Debian GNU/Linux users Git surpassed Subversion's
popularity in the mid 2011. Below is a graph from Debian's automatic
popularity contest. It's a "vote" graph which shows if the binary files
in the packages have been accessed recently (atime).

http://qa.debian.org/popcon-graph.php?packages=git%2Cmercurial%2Cbzr%2Csubversion&show_vote=on&want_legend=on&from_date=2010-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

The "install" graph looks the same. This is just about machines that
have packages installed.

http://qa.debian.org/popcon-graph.php?packages=git%2Cmercurial%2Cbzr%2Csubversion&show_installed=on&want_legend=on&from_date=2010-05-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

Here's again the "vote" graph but only for bzr and mercurial packages.
It seems that Bzr's trend is subtle downhill but it's too early to tell
(Continue reading)

Eli Zaretskii | 2 Apr 19:12 2013
Picon

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

> Date: Tue, 2 Apr 2013 11:45:08 -0400
> From: Barry Warsaw <barry <at> python.org>
> Cc: Alan Mackenzie <acm <at> muc.de>, emacs-devel <at> gnu.org
> 
> I still suspect that dvcs adoption is miles behind traditional vcses such as
> Subversion.

He, Texinfo just switched from CVS to svn.

Miles Bader | 3 Apr 10:00 2013
Picon

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

Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Tue, 2 Apr 2013 11:45:08 -0400
>> From: Barry Warsaw <barry <at> python.org>
>> Cc: Alan Mackenzie <acm <at> muc.de>, emacs-devel <at> gnu.org
>> 
>> I still suspect that dvcs adoption is miles behind traditional vcses such as
>> Subversion.
>
> He, Texinfo just switched from CVS to svn.

The Lua maintainers still use RCS... :]

[No diss on them, btw, I love Lua, and they do a great job with it!]

-miles

--

-- 
永日の 澄んだ紺から 永遠へ

Christopher Schmidt | 2 Apr 17:16 2013

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

Alan Mackenzie <acm <at> muc.de> writes:
> hg wins here hands down.  Given how many commands there are in git,
> having to study multi-hundred line man pages here seems suboptimal.
> Indeed, having to learn git could be a barrier to participation in
> projects which use it.

git is incredibly powerful.  This is reflected by the amount and length
of the official documentation.

There is no need to study all git-related man-pages.  When it comes to
understanding and implementing a conservative workflow one just needs a
handful of different commands with about one or two arguments each.

I really like git's man pages.  In my opinion, the documentation is
precise, meaningful and does not leave much room any questions.

A lot of books have been written about git.  In particular, please check

    http://git-scm.com/book

This one is both tutorial and reference and has been translated to many
languages.

I do not think it takes much time to master git.

        Christopher

Alan Mackenzie | 2 Apr 17:47 2013
Picon

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

On Tue, Apr 02, 2013 at 04:16:19PM +0100, Christopher Schmidt wrote:
> Alan Mackenzie <acm <at> muc.de> writes:
> > hg wins here hands down.  Given how many commands there are in git,
> > having to study multi-hundred line man pages here seems suboptimal.
> > Indeed, having to learn git could be a barrier to participation in
> > projects which use it.

> git is incredibly powerful.  This is reflected by the amount and length
> of the official documentation.

Indeed.  hg has about the same degree of power (reflected in the fact
that many large projects use it), yet its entire documentation is in a
single, easily searchable ~7000 line man page.

> There is no need to study all git-related man-pages.  When it comes to
> understanding and implementing a conservative workflow one just needs a
> handful of different commands with about one or two arguments each.

As a beginner, one must first work out what these commands are, then
continually look Somewhere Else to be reminded how to use them.  hg is
far superior here, in that its commands are fewer (and thus more
powerful) and its help command is actually helpful.

> I really like git's man pages.  In my opinion, the documentation is
> precise, meaningful and does not leave much room any questions.

man pages are suboptimal for beginners.  It's largely beginners who'll
want to type "git help ....".

> A lot of books have been written about git.  In particular, please check
(Continue reading)

Barry Warsaw | 2 Apr 17:42 2013

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

On Apr 02, 2013, at 02:54 PM, Alan Mackenzie wrote:

>One aspect not yet touched upon is documentation.  Compare, for example,
>{git,hg,bzr} help merge.  git dumps you into a ~300 line man page.  hg
>outputs a concise, yet complete ~40-line summary.  bzr outputs a rambling
>~100 line essay which might say what the command does, but it's difficult
>to tell.
>
>hg wins here hands down.  Given how many commands there are in git,
>having to study multi-hundred line man pages here seems suboptimal.
>Indeed, having to learn git could be a barrier to participation in
>projects which use it.

Fully agree.  In many cases, git is even worse since it assumes you understand
the technical jargon and implementation details of the system just to be able
to guess at which of the many variations of a command you should pick.

-Barry
Karl Fogel | 26 Mar 21:55 2013

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

"John Wiegley" <johnw <at> newartisans.com> writes:
>We have often debated the merits of Git vs. Bazaar, and which one the GNU
>project should use for Emacs development.  I think now is an appropriate time
>to revisit this decision.
>
>My main reason for bringing this up again is that Bazaar development has
>effectively stalled.  There are major bugs which have been in their
>bug-tracker for years now -- bugs affecting Emacs development, such as the
>ELPA repository -- whach have been ignored all this time.  There are also
>other factors, but this one alone is significant enough that I think it
>justifies us switching over to Git all by itself.
>
>So, to Richard as the undisputed Czar of all things Emacs: can we now, pretty
>please, switch to Git? :)  I'm happy to coordinate whatever resources it takes
>to make a full and faithful conversion from Bzr happen as soon as possible.

+1

Calling Bazaar a "GNU project" is becomes more meaningless the slower
Bzr's development gets.  The last release candidate, 2.6b2, was in July
2012.  That announcement said "2.6.0 is planned to be released in August
2012".

I understand that unplanned things can delay a major release -- this can
happen to any project.  But it's a little more disturbing when there's a
cessation of "beta" releases *on the way* to the next major release.  If
it's in the release testing process, then we should see successive beta
releases, not inactivity.

There are no announcements at all from after 24 July 2012, on the Bazaar
(Continue reading)

Juanma Barranquero | 27 Mar 00:00 2013
Picon

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

On Tue, Mar 26, 2013 at 9:55 PM, Karl Fogel <kfogel <at> red-bean.com> wrote:

> The last release candidate, 2.6b2, was in July 2012.

And no Windows installer for that RC was ever built. RC2 has not been
tested on Windows, except perhaps by those that build their own Bazaar
(likely not many, as it isn't the easiest of targets to build to, I
think).

   J

Richard Stallman | 27 Mar 05:02 2013
Picon
Picon

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

The maintainer says he is fixing some bugs, and I asked him
just yesterday to fix the ELPA branch bug.
I'd like to give him a reasonable time to do this.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Thierry Volpiatto | 27 Mar 07:38 2013
Picon

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

Richard Stallman <rms <at> gnu.org> writes:

> The maintainer says he is fixing some bugs, and I asked him
> just yesterday to fix the ELPA branch bug.
> I'd like to give him a reasonable time to do this.

When next python version will be adopted by all distributions, expect
the amount of bugs in bzr to grow, and when python 3.++ will be adopted
expect bzr will not work anymore.

--

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Dmitry Gutov | 27 Mar 09:43 2013
Picon

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

Richard Stallman <rms <at> gnu.org> writes:

> The maintainer says he is fixing some bugs, and I asked him
> just yesterday to fix the ELPA branch bug.

Isn't this a bit late? The bug is 1.5 years old. Was he not aware of it
before?

And considering that the decision to move ELPA to Git has already been
made, fixing that specific bug shouldn't make a difference. This
discussion is about Emacs core.

Stephen J. Turnbull | 27 Mar 10:13 2013
Picon

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

Dmitry Gutov writes:
 > Richard Stallman <rms <at> gnu.org> writes:
 > 
 > > The maintainer says he is fixing some bugs, and I asked him
 > > just yesterday to fix the ELPA branch bug.
 > 
 > Isn't this a bit late? The bug is 1.5 years old. Was he not aware of it
 > before?

No, true, yes, and Richard is aware of all those facts, I'm sure.
Good projects go dormant for years, sometimes.  Richard knows and
accepts that.  Obviously, he's trying to do something to reverse it in
this case because it's important to Emacs to have a good VCS.

Dmitry, please go back and review the original discussion that led to
selection of Bazaar.  Everything you need to know will be in the
emacs-devel archives.  While I strongly disagreed with that decision,
and equally strongly disagree with this one, Richard's position is
entirely consistent across time.  If you're going to change his mind,
you're going to need to deal with his reasons, which already were
strong enough to overcome objections to Bazaar (which was much farther
behind git in almost all ways at that time).  I myself don't have any
strong new reasons, sorry, so I can't help you.

Allen S. Rout | 27 Mar 16:49 2013
Picon

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

On 03/27/2013 05:13 AM, Stephen J. Turnbull wrote:
> please go back and review the original discussion that led to
> selection of Bazaar.  [...]
> 

Might some kind soul decorate this with e.g. a GMANE reference or other
similar?

- Allen S. Rout

Dmitry Gutov | 27 Mar 17:32 2013
Picon

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

"Allen S. Rout" <asr <at> ufl.edu> writes:

> On 03/27/2013 05:13 AM, Stephen J. Turnbull wrote:
>> please go back and review the original discussion that led to
>> selection of Bazaar.  [...]
>> 
>
> Might some kind soul decorate this with e.g. a GMANE reference or other
> similar?

If I found the right discussion, these two messages:

http://thread.gmane.org/gmane.emacs.devel/90798/focus=92070
http://thread.gmane.org/gmane.emacs.devel/90798/focus=91330

seem to indicate that Bazaar was considered a good enough tech at the
time, and that politics were coming second, or at least were not an
overriding factor.

If Bazaar had been in bad shape even then, I don't see anyone mentioning
that in the discussion (admittedly, I haven't read every message).

Stephen J. Turnbull | 27 Mar 19:55 2013
Picon

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

Dmitry Gutov writes:

 > If I found the right discussion, these two messages:
 > 
 > http://thread.gmane.org/gmane.emacs.devel/90798/focus=92070
 > http://thread.gmane.org/gmane.emacs.devel/90798/focus=91330
 > 
 > seem to indicate that Bazaar was considered a good enough tech at the
 > time, and that politics were coming second, or at least were not an
 > overriding factor.

I read your citations as indicating exactly the opposite.  Especially
in context of the actual discussion, where the technical demands for
"good enough" were minimized.

In any case, here's the original thread started by Eric Raymond, where
Richard says from the get-go that the determining factor is GNU-ness:

http://thread.gmane.org/gmane.emacs.devel/85669/focus=85669

 > If Bazaar had been in bad shape even then, I don't see anyone
 > mentioning that in the discussion (admittedly, I haven't read every
 > message).

It was known at the time that Bazaar's current version was slow and
repos were bloated.  (Part of why Python rejected it in March 2009, a
year later.  See http://www.python.org/dev/peps/pep-0374/#decision and
the following discussion.)  The thread starting at msg 85669 on Gmane
also provides plenty of evidence that Bazaar performed poorly compared
to git and Mercurial.
(Continue reading)

Richard Stallman | 27 Mar 18:15 2013
Picon
Picon

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

    > The maintainer says he is fixing some bugs, and I asked him
    > just yesterday to fix the ELPA branch bug.

    Isn't this a bit late? The bug is 1.5 years old. Was he not aware of it
    before?

The point is, I am trying to determine whether Bzr is effectively
maintained or not.  I'd rather get a Yes answer than a No answer.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Juanma Barranquero | 27 Mar 18:56 2013
Picon

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

On Wed, Mar 27, 2013 at 6:15 PM, Richard Stallman <rms <at> gnu.org> wrote:

> The point is, I am trying to determine whether Bzr is effectively
> maintained or not.

The answer to that question should be obvious by looking at the public
repository and developers' list. Perhaps they are maintaing it
internally, or perhaps they intend to maintain it again in the (near
or not-so-near) future. But right now, and for quite a while, the
answer to "is effectively maintained?" cannot be other than "not".

    J

John Yates | 27 Mar 19:32 2013

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

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.
Richard, can I assume that you are familiar with at least some of
these posting?

/john

On Wed, Mar 27, 2013 at 1:56 PM, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> On Wed, Mar 27, 2013 at 6:15 PM, Richard Stallman <rms <at> gnu.org> wrote:
>
>> The point is, I am trying to determine whether Bzr is effectively
>> maintained or not.
>
> The answer to that question should be obvious by looking at the public
> repository and developers' list. Perhaps they are maintaing it
> internally, or perhaps they intend to maintain it again in the (near
> or not-so-near) future. But right now, and for quite a while, the
> answer to "is effectively maintained?" cannot be other than "not".
>
>     J
>

Werner LEMBERG | 27 Mar 21:25 2013
Picon

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


> 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.
> Richard, can I assume that you are familiar with at least some of
> these posting?

For example here:

  http://stationary-traveller.eu/pages/bzr-a-retrospective.html

     Werner

Richard Stallman | 28 Mar 05:20 2013
Picon
Picon

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

    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.html
before.  It says many useful things but does not say anything about
the crucial question: whether Bzr is maintained enough or not.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Leo Liu | 28 Mar 06:33 2013
Face
Picon

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

On 2013-03-28 12:20 +0800, Richard Stallman wrote:
> 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.

Exactly. Your time will be better spent on issues other than BZR.

Most GNU projects aren't using BZR as you might be aware. While helping
BZR fixing bugs might be a gain for BZR, it is a loss as a whole for
GNU. Volunteers spend their spare time on GNU projects and if 20% of
that time is taken up by wrestling with BZR, it becomes costly to the
point discouraging people from joining.

For the greater good of GNU, move off BZR seems like the only sound
choice.

Leo

joakim | 28 Mar 08:53 2013
Picon

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

Richard Stallman <rms <at> gnu.org> 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
(Continue reading)

Thien-Thi Nguyen | 28 Mar 13:21 2013
Picon

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

() joakim <at> verona.se
() Thu, 28 Mar 2013 08:53:01 +0100

   Heres my take:

   [...]
   - 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.

Recently, Guile-SDL was accepted as a GNU project (transition wip,
announcement RSN).  It wraps libsdl (and friends) for Guile 1.4 and up.

I imagine the wrapping of libgit2 would entail similar work and hereby
volunteer to mentor anyone who steps forward on the techniques Guile-SDL
uses.  (The majority of the hair is Guile-version-specific shimming.)

Like Guile-SDL, i think Guile-Git (or whatever) would be best if started
as non-GNU and GPLv3+, and only after some refinement worry about being
accepted as GNU.  The important part is the GPLv3+.

   I only have very small resources to
   devote personally towards it though.

I know what you mean.  Everyone should be warned that my mentoring style
is best-suited for those who probably don't need a mentor.  :-D
(Continue reading)

Richard Stallman | 28 Mar 19:59 2013
Picon
Picon

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

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

When I have to decide whether a maintainer is doing an adequate job or
needs to be replaced, I pay attention to whatever relevant information
I get.  However, to give users "a say" in the decision seems improper,
so I don't do that.

    - Incrementally produce a GNU-Git, which is maintained by GNU

Could you explain what you are proposing?  A fork of Git?
A replacement for Git?

As of now I don't know of a reason to do either of those things.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Karl Fogel | 28 Mar 22:10 2013

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

Richard Stallman <rms <at> gnu.org> 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
(Continue reading)

Richard Stallman | 29 Mar 04:48 2013
Picon
Picon

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

    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

Because more than Emacs is at stake here.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Juanma Barranquero | 29 Mar 04:53 2013
Picon

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

On Fri, Mar 29, 2013 at 4:48 AM, Richard Stallman <rms <at> gnu.org> wrote:

> Because more than Emacs is at stake here.

Have the Bazaar developers (or Canonical) ever given more than lip
service to Bazaar being a GNU project?

   J

Karl Fogel | 29 Mar 19:05 2013

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

Richard Stallman <rms <at> gnu.org> writes:
>    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
>
>Because more than Emacs is at stake here.

Let me rephrase to just: "Why not delegate?"

That is, you should either devote enough time to evaluating Bzr's
maintenance state to get a reliable answer, or delegate to someone who
can do so.

Since there are people here who have *already* put in more time & effort
to find that answer than you have (and than you will be able to, given
your self-described constraints), there is an existence proof that
delegation is feasible.

My point is not that the Emacs maintainers would do the investigation.
It's that they would rely on those who have been following Bzr more
closely than you have, and who have researched it in greater depth
recently, and make a decision based on what those people discover.

Instead, you're asking the maintainers to rely on your investigation...
yet you clearly don't have time to do a good job.  This is a poor use of
everyone's time -- yours, but also that of the other devs -- and does
not serve the GNU project well in any case.  The fact that "more than
Emacs is at stake here" just makes this even worse!

Another solution is for you to spend enough time to get a reliable
answer.  That would mean looking through the Bazaar mailing lists and
(Continue reading)

Richard Stallman | 29 Mar 22:12 2013
Picon
Picon

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

I already have a plan for how to proceed on this, and I am doing it.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Richard Stallman | 28 Mar 05:20 2013
Picon
Picon

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

    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.

The maintainer says he and others fix bugs.  I have asked him to fix a
specific bug.  Would someone please help, by pointing him at the report
for that bug?

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Juanma Barranquero | 28 Mar 13:26 2013
Picon

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

On Thu, Mar 28, 2013 at 5:20 AM, Richard Stallman <rms <at> gnu.org> wrote:

> I can't do that -- it is too big a job.

My point is not that you should spend time on it, but that it is
painfully evident for those of us that do follow the Bazaar
developers' list.

> The maintainer says he and others fix bugs.  I have asked him to fix a
> specific bug.

Even if the maintainers fix these bugs by your request, that means
nothing IMHO. There seems to be no long-term commitment, and without
that, the Bazaar development community doesn't seem very healthy right
now.

    Juanma

Stefan Monnier | 28 Mar 16:11 2013
Picon

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

> Even if the maintainers fix these bugs by your request, that means
> nothing IMHO.

Indeed.  We have already pleaded to fix this bug several times.

        Stefan

Richard Stallman | 28 Mar 19:58 2013
Picon
Picon

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

    My point is not that you should spend time on it, but that it is
    painfully evident for those of us that do follow the Bazaar
    developers' list.

_Some_ conclusion is painfully evident to you, but it is not clear
what your conclusion implies for the decision I face.  We are, in
essence, miscommunicating.

    Even if the maintainers fix these bugs by your request, that means
    nothing IMHO.

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 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.

Without this help, my decision will be stuck in the same limbo where
it has been stuck for some months.  Please help me out.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
(Continue reading)

John Wiegley | 28 Mar 20:26 2013

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

>>>>> Richard Stallman <rms <at> gnu.org> writes:

> 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.

I think your approach here is perfectly reasonable, Richard, and commendable.
It is not a decision to be taken lightly -- especially since you'd be choosing
to replace the use of a GNU project with a non-GNU one -- so I'll help you
gather whatever evidence you need.

The Bazaar bug in question, concerning bzr and ELPA, is here:

    https://bugs.launchpad.net/bzr/+bug/937101

John

Eli Zaretskii | 28 Mar 20:49 2013
Picon

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

> From: "John Wiegley" <johnw <at> newartisans.com>
> Date: Thu, 28 Mar 2013 19:26:58 +0000
> Cc: emacs-devel <at> gnu.org
> 
> The Bazaar bug in question, concerning bzr and ELPA, is here:
> 
>     https://bugs.launchpad.net/bzr/+bug/937101

It is a duplicate of

  https://bugs.launchpad.net/bzr/+bug/830947

Richard Stallman | 29 Mar 04:47 2013
Picon
Picon

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

    The Bazaar bug in question, concerning bzr and ELPA, is here:

	https://bugs.launchpad.net/bzr/+bug/937101

Thanks.  That looks like exactly what I need.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Eli Zaretskii | 28 Mar 20:44 2013
Picon

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

> Date: Thu, 28 Mar 2013 14:58:52 -0400
> From: Richard Stallman <rms <at> gnu.org>
> Cc: emacs-devel <at> gnu.org
> 
> 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.
> 
> Without this help, my decision will be stuck in the same limbo where
> it has been stuck for some months.  Please help me out.

Sorry, I wasn't aware that you still didn't identify the bug.  Here it
is:

   https://bugs.launchpad.net/bzr/+bug/830947

A duplicate was reported here:

   https://bugs.launchpad.net/bzr/+bug/1099209

Allen S. Rout | 27 Mar 19:48 2013
Picon

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


On 03/27/2013 01:15 PM, Richard Stallman wrote:
>
> The point is, I am trying to determine whether Bzr is effectively
> maintained or not.  I'd rather get a Yes answer than a No answer.

I'm a 20-year lover of Emacs, though only the most negligible
contributor.  It might be appropriate for my two cents to be ignored by
this assemblage, but here it is.

If RMS must make a personal appeal to generate action at this moment,
even if action is forthcoming, that action cannot reasonably be laid to
the general credit of the Bzr project.

The "maintained" state of a project is not determined by response to a
single bug, but by ongoing availability and responsiveness.   Waiting
for maintainer interest to decay again so that the situation is again
unambiguous is IMO a waste of time.  A 5 year sample (the conversation
from March 2008) to now seems sufficient rope.

- Allen S. Rout

Josh | 27 Mar 21:27 2013

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

On Wed, Mar 27, 2013 at 11:48 AM, Allen S. Rout <asr <at> ufl.edu> wrote:
> I'm a 20-year lover of Emacs, though only the most negligible
> contributor.  It might be appropriate for my two cents to be ignored by
> this assemblage, but here it is.

Two more cents from another casual contributor: though I have
completed the copyright assignment paperwork and made a couple of
commits to the trunk, my experience in getting my Bzr environment set
up and pushing those commits was burdensome enough that I've been
reluctant to go through that process again in order to commit the
handful of other improvements and bug fixes that are now locked away
in my init file and thus of no use to anyone but me and people with
whom I share the code directly.  I personally would contribute more if
the Emacs source code were managed by Git, not because it is best
technically -- which indeed it may not be as Jordi so often asserts :)
-- but because it's familiar to me and thus I'd have more time
available to improve Emacs instead of battling an unfamiliar, niche,
seemingly moribund VCS.

Based on numerous comments that I've seen in #emacs over the years, I
suspect that many other casual and potential contributors are of like
mind and are less engaged with Emacs development as they might be were
Emacs to use a more mainstream VCS.  It seems to me that Emacs and the
GNU project as a whole would be best served by making it as easy as
possible for newcomers to join our community, and that migrating to
Git would go a long way toward doing so.

> The "maintained" state of a project is not determined by response to a
> single bug, but by ongoing availability and responsiveness.   Waiting
> for maintainer interest to decay again so that the situation is again
(Continue reading)

Barry Warsaw | 2 Apr 02:26 2013

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

On Mar 27, 2013, at 01:15 PM, Richard Stallman wrote:

>The point is, I am trying to determine whether Bzr is effectively
>maintained or not.  I'd rather get a Yes answer than a No answer.

Given that Bazaar is GPL v2 and the contributor agreement is not that onerous
IMHO (e.g. you retain copyright to your contributed changes), what's stopping
the user community from stepping up to help to maintain it, just like any
other free software?

If it's lack of interest, then okay, that happens with projects all the time.

If it's something else, then please identify, as it may be possible to fix
organizational or other issues to make it easier for folks to contribute to
the project and move it along, regardless of Canonical's sponsorship.

Cheers,
-Barry
Stephen J. Turnbull | 2 Apr 05:24 2013
Picon

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

Barry Warsaw writes:

 > Given that Bazaar is GPL v2 and the contributor agreement is not
 > that onerous IMHO (e.g. you retain copyright to your contributed
 > changes), what's stopping the user community from stepping up to
 > help to maintain it, just like any other free software?

Unless it's changed recently, the Canonical contributor agreement for
Bazaar is quite asymmetric, giving rights to Canonical that other
contributors don't get.

 > If it's lack of interest, then okay, that happens with projects all the time.

As Lucy van Pelt would say, "THAT'S IT!!!"  The Emacs developers have
made it plain that they're not *sufficiently* interested in
contributing fixes to the problems they encounter in Bazaar, although
the one bug that they run into in the ELPA branch is a near show-
stopper.

Why the interest is insufficient, I'm not sure, but I suspect one big
problem is that Bazaar code is in a language unfamiliar to the most
likely hackers, and it contains many complex interrelated modules that
must be understood to do much of anything.  And at the time of the
decision, Bazaar was touted as a flagship product by Mark himself, so
it seemed unlikely that Emacs hackers would need to help feed the dog.

chad | 2 Apr 10:25 2013
Picon

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

On 01 Apr 2013, at 20:24, Stephen J. Turnbull <stephen <at> xemacs.org> wrote:

> Why the interest is insufficient, I'm not sure, 

I'll speculate a bit beyond `python', and generalize from my
observations:

(D)VCS is (for the sake of this discussion) an infrastructure tool.
Reliability is very, very important; probably moreso even than
editor or compiler - because it's much easier to notice problems
early with editor or compiler, while a VCS problem can hide a
disaster for a long while (early backup software used to have similar
issues).

Bzr itself is Not Simple, and until it effectively stagnated, was
also not especially stable.  The internal models are relatively
complex, allowing bazaar to handle many different workflows, and
the structures (for example, the repository layout) were changing
relatively frequently.  When Emacs adopted bazaar, bzr was on the
cusp of a big change, with another on the horizon (looms was one
candidate; I've forgotten the name of the other).

As things slowed down inside bzr, the barriers to entry went up,rather
than down. Patches sat around bit-rotting rather than being included
or rejected, which made it hard (at least conceptually) to get up
to speed with the project. At the same time, the core thinned (Martin
Pool, for example).

None of these are impassible, but they combine to make `just use
this other thing that thousands of other projects use' awfully
(Continue reading)

Eli Zaretskii | 2 Apr 18:35 2013
Picon

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

> From: chad <yandros <at> MIT.EDU>
> Date: Tue, 2 Apr 2013 01:25:41 -0700
> Cc: Barry Warsaw <barry <at> python.org>, "Stephen J. Turnbull" <stephen <at> xemacs.org>
> 
> On 01 Apr 2013, at 20:24, Stephen J. Turnbull <stephen <at> xemacs.org> wrote:
> 
> Bzr itself is Not Simple, and until it effectively stagnated, was
> also not especially stable.  The internal models are relatively
> complex, allowing bazaar to handle many different workflows, and
> the structures (for example, the repository layout) were changing
> relatively frequently.  When Emacs adopted bazaar, bzr was on the
> cusp of a big change, with another on the horizon (looms was one
> candidate; I've forgotten the name of the other).
> 
> As things slowed down inside bzr, the barriers to entry went up,rather
> than down. Patches sat around bit-rotting rather than being included
> or rejected, which made it hard (at least conceptually) to get up
> to speed with the project. At the same time, the core thinned (Martin
> Pool, for example).

That reminds me of another project I'm familiar with: Emacs.

It is definitely "Not Simple", and the development versions many
people use every day are not terribly stable, either.  "Complex
internal models"?  we've got more than bzr could ever dream of.  I'm
hacking the display engine since 2008, and it still surprises me from
time to time.  "Frequent changes in structures"? you betcha, just look
at the logs from the last month.  "Thin core"? the guy who implemented
the display engine is no longer with us, since 10 years ago, and the
couple of others who knew a lot about redisplay are not active for at
(Continue reading)

chad | 2 Apr 19:57 2013
Picon

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


On 02 Apr 2013, at 09:35, Eli Zaretskii <eliz <at> gnu.org> wrote:

> That reminds me of another project I'm familiar with: Emacs.

When people submit patches to emacs, they typically get feedback
of some sort within a few days.  This lets potential contributors
"get their feet wet" with small changes while learning the ins and
outs of the system and the development process.  This does not seem
to be the case with bzr; that's specifically why I mentioned it.

> If I were reasoning like you do, I'd never have written the
> bidirectional display code. 

The bidi engine wasn't your first submission to Emacs, of course.
Imagine if you'd decided to start work on bidi just after multi-tty
landed, that you'd never worked on the project before, and then add
that nobody responds to your patches. That's a closer analogy to
bzr at the moment.

I'm trying to help people (after rms asked) understand why, perhaps,
bzr development is in it's current sorry state. I clearly stated
up front that I was speculating and generalizing from my own
observations, rather than stating some truths about the universe.

I hope that helps.
~Chad

Eli Zaretskii | 2 Apr 20:02 2013
Picon

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

> From: chad <yandros <at> MIT.EDU>
> Date: Tue, 2 Apr 2013 10:57:03 -0700
> Cc: "emacs-devel <at> gnu.org Development" <emacs-devel <at> gnu.org>
> 
> I'm trying to help people (after rms asked) understand why, perhaps,
> bzr development is in it's current sorry state. I clearly stated
> up front that I was speculating and generalizing from my own
> observations, rather than stating some truths about the universe.

And I was trying to communicate that I think Stephen came much closer
to the real reasons.

chad | 2 Apr 20:12 2013
Picon

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


On 02 Apr 2013, at 11:02, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: chad <yandros <at> MIT.EDU>
>> Date: Tue, 2 Apr 2013 10:57:03 -0700
>> Cc: "emacs-devel <at> gnu.org Development" <emacs-devel <at> gnu.org>
>> 
>> I'm trying to help people (after rms asked) understand why, perhaps,
>> bzr development is in it's current sorry state. I clearly stated
>> up front that I was speculating and generalizing from my own
>> observations, rather than stating some truths about the universe.
> 
> And I was trying to communicate that I think Stephen came much closer
> to the real reasons.

Ah, I missed that in your message.  I do not disagree with either
you or Stephen, and you/he are probably right about the primarily
causes.  I intended my message to point out additional issues,
since, for example, I doubt Barry Warsaw is dissuaded from working
on a project simply because it's implemented in Python. :-)

Thanks for helping me understand what you meant.

~Chad

Jose E. Marchesi | 2 Apr 14:30 2013
Picon

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


    >The point is, I am trying to determine whether Bzr is effectively
    >maintained or not.  I'd rather get a Yes answer than a No answer.

    Given that Bazaar is GPL v2 and the contributor agreement is not that onerous
    IMHO (e.g. you retain copyright to your contributed changes), what's stopping
    the user community from stepping up to help to maintain it, just like any
    other free software?

Not that onerous?  The Canonical Individual Contributor License
Agreement requires you to explicitly authorise Canonical to license the
contributed software under a proprietary license.  See section 2.3 of
the agreement.

--

-- 
Jose E. Marchesi         http://www.jemarch.net
GNU Project              http://www.gnu.org

Barry Warsaw | 2 Apr 16:02 2013

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

On Apr 02, 2013, at 02:30 PM, Jose E. Marchesi wrote:

>Not that onerous?  The Canonical Individual Contributor License
>Agreement requires you to explicitly authorise Canonical to license the
>contributed software under a proprietary license.  See section 2.3 of
>the agreement.

I *personally* have no problem with that because 1) you still retain copyright
so can do whatever you like with the contribution; 2) Canonical agrees to
*also* license the contribution under the original license (in this case,
GPL).

-Barry

Jay Belanger | 2 Apr 17:19 2013
Picon

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


> Not that onerous?  The Canonical Individual Contributor License
> Agreement requires you to explicitly authorise Canonical to license the
> contributed software under a proprietary license.  See section 2.3 of
> the agreement.

I don't know if onerous is the right word, but I find this incredibly
surprising.  There is a GNU project where, if you want to contribute,
you have to explicitly say that your contributions can be put under a
proprietary license.
Why would this be a GNU project?

Karl Fogel | 2 Apr 21:27 2013

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

Jay Belanger <jay.p.belanger <at> gmail.com> writes:
>> Not that onerous?  The Canonical Individual Contributor License
>> Agreement requires you to explicitly authorise Canonical to license the
>> contributed software under a proprietary license.  See section 2.3 of
>> the agreement.
>
>I don't know if onerous is the right word, but I find this incredibly
>surprising.  There is a GNU project where, if you want to contribute,
>you have to explicitly say that your contributions can be put under a
>proprietary license.
>Why would this be a GNU project?

Well, you have to agree that your contributions can be *non-exclusively*
put under a proprietary license.  Canonical's contributer agreement for
Bzr does not take away your ability to use and license your changes; it
merely _also_ grants Canonical the right to distribute them in some ways
that you might not otherwise permit by default.

So all it really does is open up an entity-specific exception to your
enforcement ability.

IMHO, the contributor agreement isn't a reason for or against Bzr being
a GNU Project.  But I'm not crystal clear on what it means to be a GNU
project, other than agreeing to say publicly "We are a GNU Project" and
be licensed under the GPL.

-K

Richard Stallman | 3 Apr 20:07 2013
Picon
Picon

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

      But I'm not crystal clear on what it means to be a GNU
    project, other than agreeing to say publicly "We are a GNU Project" and
    be licensed under the GPL.

Making a program GNU software means that its developers and the GNU
project agree that "This program is part of the GNU project, released
under the aegis of GNU"--and say so in the program.

This means that we normally put the program on ftp.gnu.org (although
we can instead refer to your choice of ftp site, as long as it allows
connections from anyone anywhere).

This means that the official site for the program should be on
www.gnu.org, specifically in /software/PROGRAMNAME.  Whenever you give
out the URL for the package home page, you would give this address.
It is ok to use another site for secondary topics, such as pages meant
for people helping develop the package, and for running data bases.
(We can make an exception and put the web pages somewhere else if
there is a really pressing reason.)

It means that the developers agree to pay attention to making the
program work well with the rest of the GNU system--and conversely that
the GNU project will encourage other GNU maintainers to pay attention
to making their programs fit in well with it.

Just what it means to make programs work well together is mainly a
practical matter that depends on what the program does.  But there are
a few general principles.  Certain parts of the GNU coding standards
directly affect the consistency of the whole system.  These include
the standards for configuring and building a program, and the
(Continue reading)

Karl Fogel | 3 Apr 23:34 2013

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

Richard Stallman <rms <at> gnu.org> writes:
>Making a program GNU software means that its developers and the GNU
>project agree that "This program is part of the GNU project, released
>under the aegis of GNU"--and say so in the program.
>
>This means that we normally put the program on ftp.gnu.org (although
>we can instead refer to your choice of ftp site, as long as it allows
>connections from anyone anywhere).
>
>This means that the official site for the program should be on
>www.gnu.org, specifically in /software/PROGRAMNAME.  Whenever you give
>out the URL for the package home page, you would give this address.
>It is ok to use another site for secondary topics, such as pages meant
>for people helping develop the package, and for running data bases.
>(We can make an exception and put the web pages somewhere else if
>there is a really pressing reason.)

Bazaar's home page is http://bazaar.canonical.com/.

This is what the "Home Page" link from https://launchpad.net/bzr says
(i.e., from the community's accepted development home page).

The README [1] at the top of the Bazaar source does not reference
gnu.org at all, let alone "http://www.gnu.org/software/bazaar".

The README's recommended download link and documentation links are all
at canonical.com.

In fact, if you browse to http://www.gnu.org/software/bazaar, it
redirects you to http://bazaar.canonical.com/en/.  Actually, it first
(Continue reading)

Xue Fuqiao | 4 Apr 01:20 2013
Picon

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

On Wed, 03 Apr 2013 16:34:31 -0500
Karl Fogel <kfogel <at> red-bean.com> wrote:

>  As far as I can tell, the only really meaningful way in which Bazaar
> is a "GNU project" is that GNU Emacs currently uses it.

IIRC Gnash, Mailman and Solfege also use it. (There are some other GNU
programs that use Bazaar, but I cannot remember.)

--

-- 
Xue Fuqiao
http://www.gnu.org/software/emacs/

Stephen J. Turnbull | 4 Apr 05:09 2013
Picon

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

Xue Fuqiao writes:
 > On Wed, 03 Apr 2013 16:34:31 -0500
 > Karl Fogel <kfogel <at> red-bean.com> wrote:
 > 
 > >  As far as I can tell, the only really meaningful way in which Bazaar
 > > is a "GNU project" is that GNU Emacs currently uses it.
 > 
 > IIRC Gnash, Mailman and Solfege also use it. (There are some other GNU
 > programs that use Bazaar, but I cannot remember.)

The head of the Mailman project is a Canonical employee.  IIRC, at the
time of the choice of VCS, he was working on Launchpad.  At least one
of the Gnash core developers was a Canonical employee assigned to
Bazaar development.  Those projects are more evidence of Canonical
connection than of GNU connection I would say.

On the contrary, at the time that Emacs chose Bazaar, Savannah's
support for Bazaar was rather poor; only a project that valued ideals
at almost any cost of productivity would choose it.  Savannah's
support for git was much better; the alternatives for projects that
just wanted the VCS to stay out of their way were really svn and git.
The difficulties Emacs faced would hardly have encouraged other to use
Bazaar for quite some time (it takes a couple of years for such a
reputation to disperse, let alone reverse).

On balance, usage by GNU projects is hardly evidence one way or
another for the GNU-ness of Bazaar.

But if the facts Karl reports about the website are current, that's
sad.  Except for the www.gnu.org redirect to canonical.com, those
(Continue reading)

Andreas Schwab | 4 Apr 09:23 2013

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

Xue Fuqiao <xfq.free <at> gmail.com> writes:

> On Wed, 03 Apr 2013 16:34:31 -0500
> Karl Fogel <kfogel <at> red-bean.com> wrote:
>
>>  As far as I can tell, the only really meaningful way in which Bazaar
>> is a "GNU project" is that GNU Emacs currently uses it.
>
> IIRC Gnash, Mailman and Solfege also use it.

Gnash moved on to Git about two years after the switch to Bazaar.

Andreas.

--

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Xue Fuqiao | 4 Apr 09:53 2013
Picon

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

On Thu, 04 Apr 2013 09:23:51 +0200
Andreas Schwab <schwab <at> linux-m68k.org> wrote:

> Xue Fuqiao <xfq.free <at> gmail.com> writes:
> > On Wed, 03 Apr 2013 16:34:31 -0500
> > Karl Fogel <kfogel <at> red-bean.com> wrote:

> >>  As far as I can tell, the only really meaningful way in which Bazaar
> >> is a "GNU project" is that GNU Emacs currently uses it.

> > IIRC Gnash, Mailman and Solfege also use it.

> Gnash moved on to Git about two years after the switch to Bazaar.

I haven't paid close attention to Gnash development for years, sorry.

--

-- 
Xue Fuqiao
http://www.gnu.org/software/emacs/

Richard Stallman | 5 Apr 04:09 2013
Picon
Picon

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

We don't insist that every GNU package follow every one of these
rules.  Bazaar already had a site and there was no reason to insist on
moving it.

You are attacking the GNU Project for being somewhat flexible.  How
about ceasing the attacks?  All they will achieve is to create enmity.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Leo Liu | 5 Apr 08:46 2013
Face
Picon

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

On 2013-04-05 10:09 +0800, Richard Stallman wrote:
> You are attacking the GNU Project for being somewhat flexible.  How
> about ceasing the attacks?  All they will achieve is to create enmity.

How is he attacking GNU? I read his message as warning GNU or you honour
being used as a gun by some random commercial entity.

Leo

Karl Fogel | 5 Apr 17:01 2013

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

Richard Stallman <rms <at> gnu.org> writes:
>We don't insist that every GNU package follow every one of these
>rules.  Bazaar already had a site and there was no reason to insist on
>moving it.

The site that Bazaar had when it became a GNU project was not this site.
It was either bazaar-vcs.org or a predecessor domain.  Later, *after*
becoming a GNU Project, they moved their home page to canonical.com,
instead of choosing something at gnu.org.

Naturally, this causes me to ask in what sense they are meaningfully a
GNU project!

Richard Stallman | 6 Apr 16:04 2013
Picon
Picon

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

    The site that Bazaar had when it became a GNU project was not this site.
    It was either bazaar-vcs.org or a predecessor domain.  Later, *after*
    becoming a GNU Project, they moved their home page to canonical.com,
    instead of choosing something at gnu.org.

I did not know that.  It was not a good thing to do.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Richard Stallman | 3 Apr 02:06 2013
Picon
Picon

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

Now that Canonical is not developing Bazaar, there is no more reason
for anyone to sign their contributor agreement.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Stefan Monnier | 27 Mar 14:07 2013
Picon

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

> The maintainer says he is fixing some bugs, and I asked him
> just yesterday to fix the ELPA branch bug.
> I'd like to give him a reasonable time to do this.

I'm not interested.  GNU ELPA will move to Git, which will make lots of
things easier since it merges from various external branches, 99% of
which use Git (which currently forces me to do a good bit of gymnastics
to use bzr-git and then work around some of its limitations, which will
never be fixed because they can't really be called bugs).

        Stefan

Richard Stallman | 28 Mar 05:19 2013
Picon
Picon

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

    > The maintainer says he is fixing some bugs, and I asked him
    > just yesterday to fix the ELPA branch bug.
    > I'd like to give him a reasonable time to do this.

    I'm not interested.

It is important for the GNU Project to see if we can get Bzr
bugs fixed.  If you reported the bug, could you tell him
enough to see which bug this is?

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Stefan Monnier | 28 Mar 13:47 2013
Picon

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

> It is important for the GNU Project to see if we can get Bzr bugs fixed.

Whether we can, in theory, is not very important.  As for practice,
I know that we can't, at least not without devoting way too many resources.

        Stefan "who generally likes Bzr and uses it for all his own branches"

John Wiegley | 28 Mar 14:25 2013

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

>>>>> Richard Stallman <rms <at> gnu.org> writes:

> It is important for the GNU Project to see if we can get Bzr bugs fixed.  If
> you reported the bug, could you tell him enough to see which bug this is?

Richard, I think the fact that we've had to involve you in order to carry the
weight we need to get this bug fixed, is the very point.  Bzr is not advancing
well enough on its own to deserve to be our VCS.

John

Bastien | 28 Mar 14:57 2013
Picon

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

Richard Stallman <rms <at> gnu.org> writes:

> It is important for the GNU Project to see if we can get Bzr
> bugs fixed.

If GNU developers were asked to use GNU Hurd and to wait for Hurd
bugs to be fixed because it is important to see if we can get them
fixed, I don't think anyone would find it is an efficient way of
supporting the GNU project--because the kernel is a central piece,
and its limitations would affect our ability to contribute to GNU.

I think the same argument applies to bzr as a dVCS: it is not just
another GNU software, it's the software that we use the most often
after Emacs.

--

-- 
 Bastien

Richard Stallman | 28 Mar 19:59 2013
Picon
Picon

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

    If GNU developers were asked to use GNU Hurd and to wait for Hurd
    bugs to be fixed

If the GNU Hurd were as usable and developed as Bzr is,
I might well give that approach a try to get the Hurd into use.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

chad | 28 Mar 20:48 2013
Picon

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

For whatever reason, these bugs are no longer found by launchpad's
search function (for me, at least - launchpad suffered several
`temporary errors' while I tried to find these).  There is, as far
as I know, no way to look at these without using a web browser.

The bug in question is 18 months old:

	https://bugs.launchpad.net/bzr/+bug/830947

It was re-reported by emacs developers more than a year ago:

	https://bugs.launchpad.net/bzr/+bug/937101

Almost exactly a year ago, the bazaar people downgraded the bug
importance from `High' to `Low'.  Multiple requests from Chong
Yidong since then have gone unanswered.

In the interest of helping you determine if the project as a whole
is actively maintained or not, it's worth pointing out the current
announcement from the bazaar team:

	https://launchpad.net/bzr/+announcement/10362
	"2.6.0 is planned to be released in August 2012."

Looking at the branch of bzr marked as "the current focus of
development", there are 66 branches proposed for merging (i.e.
there's lots of patches waiting to be examined and either rejected
or accepted).  There is exactly one change to the current dev tree
this year, that makes their test suite work with last October's
Ubuntu release.  The most recent change that looks (to my non-expert
(Continue reading)

Bastien | 28 Mar 21:59 2013
Picon

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

Richard Stallman <rms <at> gnu.org> writes:

>     If GNU developers were asked to use GNU Hurd and to wait for Hurd
>     bugs to be fixed
>
> If the GNU Hurd were as usable and developed as Bzr is,
> I might well give that approach a try to get the Hurd into use.

If GNU Hurd were as usable and developed and *unmaintained* as bzr,
then my guess is that it would be hard to convince GNU contributors
to use it.

I'm all for considering the GNU project as a whole, and supporting
other GNU projects is a good goal.  But IMO this goal should not
hurt the whole dynamic: relying on unmaintained software (or poorly
maintained) is just... depressing.

If Mercurial (or another dVCS) is good enough, well maintained,
willing to become a GNU project and to use GPLv3+--I'd be glad to
learn it and to use it for Emacs.

--

-- 
 Bastien

Michael Welsh Duggan | 27 Mar 05:15 2013

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

"John Wiegley" <johnw <at> newartisans.com> writes:

> We have often debated the merits of Git vs. Bazaar, and which one the GNU
> project should use for Emacs development.  I think now is an appropriate time
> to revisit this decision.

I see these Git versus Bazaar arguments pop up every now and then on
this forum.  I must admit my experience with Git has been better than
that with Bazaar, but I have to ask, why isn't Mercurial being
considered?  From a license perspective, Mercurial is GPLv2+, while Git
is GPLv2.  I found Mercurial's command-line UI much easier to learn and
understand than Git, and I believe the two are fairly comparable in
power.

Or maybe I should just shut up before I start a new round of endless
DCVS discussion...

--

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

Leo Liu | 27 Mar 07:38 2013
Face
Picon

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

On 2013-03-27 12:15 +0800, Michael Welsh Duggan wrote:
> I see these Git versus Bazaar arguments pop up every now and then on
> this forum.  I must admit my experience with Git has been better than
> that with Bazaar, but I have to ask, why isn't Mercurial being
> considered?  From a license perspective, Mercurial is GPLv2+, while Git
> is GPLv2.  I found Mercurial's command-line UI much easier to learn and
> understand than Git, and I believe the two are fairly comparable in
> power.

The longevity of the project is very important. git being used for the
kernel guarantees its healthy growth for decades to come by then a
native version system will be built in emacs.

Let's not muddy the water with another tool that is seemingly adequate.
BZR was seemingly adequate and was regarded could do the job well. Now
years later we are back to square one.

I wish we could move directly to a tool that can serve us for a long
time and have it stayed out of the way of hacking on emacs.

Leo

Giorgos Keramidas | 1 Apr 00:01 2013
Picon

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

On 2013-03-27 14:38, Leo Liu <sdl.web <at> gmail.com> wrote:
>On 2013-03-27 12:15 +0800, Michael Welsh Duggan wrote:
>> I see these Git versus Bazaar arguments pop up every now and then on
>> this forum.  I must admit my experience with Git has been better than
>> that with Bazaar, but I have to ask, why isn't Mercurial being
>> considered?  From a license perspective, Mercurial is GPLv2+, while
>> Git is GPLv2.  I found Mercurial's command-line UI much easier to
>> learn and understand than Git, and I believe the two are fairly
>> comparable in power.
>
> The longevity of the project is very important. git being used for the
> kernel guarantees its healthy growth for decades to come by then a
> native version system will be built in emacs.
>
> Let's not muddy the water with another tool that is seemingly
> adequate.  BZR was seemingly adequate and was regarded could do the
> job well. Now years later we are back to square one.
>
> I wish we could move directly to a tool that can serve us for a long
> time and have it stayed out of the way of hacking on emacs.

Mercurial is used for Python itself (and quite a few other large
projects), so its longevity is not really a very difficult question.
It will be here for at least as long as Python, which Bazaar also uses.

While there is merit in the idea that we shouldn't muddy the waters with
too many DVCS, it's also arguably a good idea to look at more than one
option if the decision is made to switch away from Bazaar.

(Continue reading)

Xue Fuqiao | 1 Apr 01:00 2013
Picon

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

On Mon, 1 Apr 2013 00:01:37 +0200
Giorgos Keramidas <gkeramidas <at> gmail.com> wrote:

> > The longevity of the project is very important. git being used for the
> > kernel guarantees its healthy growth for decades to come by then a
> > native version system will be built in emacs.
> > Let's not muddy the water with another tool that is seemingly
> > adequate.  BZR was seemingly adequate and was regarded could do the
> > job well. Now years later we are back to square one.
> > I wish we could move directly to a tool that can serve us for a long
> > time and have it stayed out of the way of hacking on emacs.

> Mercurial is used for Python itself (and quite a few other large
> projects), so its longevity is not really a very difficult question.
> It will be here for at least as long as Python, which Bazaar also uses.

But Bazaar is used for Ubuntu[1], GNU Emacs[2], CEDET[3], GNU Mailman[4],
Drizzle[5], Inkscape[6], Bugzilla[7], VM[8] and many other projects.

Footnotes:
[1] https://code.launchpad.net/ubuntu
[2] http://bzr.savannah.gnu.org/lh/emacs
[3] http://cedet.bzr.sourceforge.net/bzr/cedet/code/trunk/changes
[4] https://code.launchpad.net/mailman
[5] https://code.launchpad.net/drizzle
[6] https://code.launchpad.net/~inkscape.dev
[7] http://bzr.mozilla.org/bugzilla/
[8] https://code.launchpad.net/vm

--

-- 
(Continue reading)

Giorgos Keramidas | 1 Apr 01:40 2013
Picon

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

On 2013-04-01 07:00, Xue Fuqiao <xfq.free <at> gmail.com> wrote:
> On Mon, 1 Apr 2013 00:01:37 +0200
> Giorgos Keramidas <gkeramidas <at> gmail.com> wrote:
>
> > > The longevity of the project is very important. git being used for the
> > > kernel guarantees its healthy growth for decades to come by then a
> > > native version system will be built in emacs.
> > > Let's not muddy the water with another tool that is seemingly
> > > adequate.  BZR was seemingly adequate and was regarded could do the
> > > job well. Now years later we are back to square one.
> > > I wish we could move directly to a tool that can serve us for a long
> > > time and have it stayed out of the way of hacking on emacs.
>
> > Mercurial is used for Python itself (and quite a few other large
> > projects), so its longevity is not really a very difficult question.
> > It will be here for at least as long as Python, which Bazaar also uses.
>
> But Bazaar is used for Ubuntu[1], GNU Emacs[2], CEDET[3], GNU Mailman[4],
> Drizzle[5], Inkscape[6], Bugzilla[7], VM[8] and many other projects.
>
> Footnotes:
> [1] https://code.launchpad.net/ubuntu
> [2] http://bzr.savannah.gnu.org/lh/emacs
> [3] http://cedet.bzr.sourceforge.net/bzr/cedet/code/trunk/changes
> [4] https://code.launchpad.net/mailman
> [5] https://code.launchpad.net/drizzle
> [6] https://code.launchpad.net/~inkscape.dev
> [7] http://bzr.mozilla.org/bugzilla/
> [8] https://code.launchpad.net/vm

(Continue reading)

Stephen J. Turnbull | 1 Apr 02:50 2013
Picon

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

Giorgos Keramidas writes:

 > Of course.  I do not presume to say that Mercurial is going to be around
 > for more than $FOO,

As a program, CVS is still "around" and someone as authoritative (in
Emacs) as Stefan has had good words to say for it. :-)  Heck, I still
use RCS in some contexts.

The right question is "how much longer will CVS *the project* be
around?"  The answer to that is that that project died years ago.  git
seems to be moving much faster than Mercurial now, although Mercurial
development is far from "stopped".

Regarding git vs. hg from the viewpoint of Emacs:

The senior Python developers are almost all of the school that VC is a
necessary nuisance, so they don't display much interest in the VC as
long as their workflow continues smoothly.  For various reasons, their
workflow is much heavier weight than any VC is, so VC features are a
small consideration to them.  They probably won't change again until
that future generation of VCSes has as great advantage over Mercurial
as Mercurial (and other DVCSes) had over CVS 5 years ago.  (Really
good subtree/submodule support, or really good bidirectional merge
support would probably do it.)  Nor is there a strong grass-roots
movement to replace Mercurial, or voices demanding more features in
the VCS.

I believe that Emacs is different.  Although some senior developers
(rms, eliz, and Handa-san prominent among them) argued at the time for
(Continue reading)

Eli Zaretskii | 1 Apr 07:54 2013
Picon

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

> From: "Stephen J. Turnbull" <stephen <at> xemacs.org>
> Date: Mon, 01 Apr 2013 09:50:29 +0900
> Cc: Xue Fuqiao <xfq.free <at> gmail.com>, Michael Welsh Duggan <mwd <at> md5i.com>,
> 	Leo Liu <sdl.web <at> gmail.com>, emacs-devel <at> gnu.org
> 
> Emacs developers as a group are pretty sensitive to improvements in
> the VCS, and therefore it would be "nice" if they could have the
> leading VCS most of the time.
> 
> It is my opinion that the architecture of git (including the plethora
> of plumbing commands that people seem to love to hate) makes it the
> odds-on favorite for the role of "leading VCS", more than Mercurial.

Then why did XEmacs choose Mercurial, and did not switch even now?

Stephen J. Turnbull | 1 Apr 08:36 2013
Picon

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

Eli Zaretskii writes:

 > Then why did XEmacs choose Mercurial, and did not switch even now?

The main reason was that Mike (who had used Mercurial heavily on some
other projects) beat me to getting a reasonably complete conversion
(which is quite broken in some ways, but it almost never matters even
for exercising an idle curiosity, and it's never been a hindrance to
real work).  Several people expressed a a preference for the Mercurial
CLI, and at least one guy worked for Sun where Mercurial was the
"official" VCS at that time.  OTOH, at that time, it wasn't clear to
me that git was going to be more featureful than Mercurial so I didn't
fight it.

Right now Mercurial is a well-maintained tool with some ongoing
development whose only real downside[1] is that it isn't the market
leader.  So we stick with what we've got.

If a project is going to change (but for Emacs, my money is on "not
this year", Richard seems pretty adamant), what I wrote about git
being the market leader would matter in choosing a successor.

Footnotes: 
[1]  I hate the way "named branches" are implemented in Mercurial, but
I find Mercurial queues to be an adequate substitute for git-style
branching for most work.

Stefan Monnier | 3 Apr 20:59 2013
Picon

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

> small consideration to them.  They probably won't change again until
> that future generation of VCSes has as great advantage over Mercurial
> as Mercurial (and other DVCSes) had over CVS 5 years ago.  (Really
> good subtree/submodule support, or really good bidirectional merge
> support would probably do it.)

While I have used a various VCS (including the obscure MetaCVS, which
I used enough to write vc-mcvs.el), your description of Python
developers sounds very applicable to me w.r.t to Emacs's trunk.
Just like I didn't fight Richard's choice of Bazaar, I don't care very
much whether we keep using Bazaar or we change to Git, Monotone, Darcs,
Mercurial, OpenCM, Fossil, younameit.

> To summarize, Emacs developers as a group are pretty sensitive to
> improvements in the VCS, and therefore it would be "nice" if they
> could have the leading VCS most of the time.

The only thing I care for now is to move away from Bazaar for the `elpa'
branch because Bazaar can't handle it properly.

        Stefan

Xue Fuqiao | 1 Apr 10:33 2013
Picon

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

On Mon, 1 Apr 2013 01:40:03 +0200
Giorgos Keramidas <gkeramidas <at> gmail.com> wrote:

> The real argument I was trying to make is 'the fact that project X uses
> bzr/hg/git today doesn't really constitute a very strong argument for
> the longevity of said VCS'.

Right, that's also what I was trying to express.  (I deliberately put
Emacs into the list.)

--

-- 
Xue Fuqiao
http://www.gnu.org/software/emacs/

John Wiegley | 1 Apr 19:47 2013

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

>>>>> Giorgos Keramidas <gkeramidas <at> gmail.com> writes:

> Mercurial is used for Python itself (and quite a few other large projects),
> so its longevity is not really a very difficult question.  It will be here
> for at least as long as Python, which Bazaar also uses.

The reason (personally) why I do not want Mercurial to become the Emacs VCS is
for the same reason I don't like bzr: Because it's not used by a *single*
project whose VCS I track or contribute to.  I don't know the UI, and have
never had any reason to know the UI.  I'm not even sure I have Mercurial
installed!

Meanwhile, the number of Git repositories on my machine today: 457.

I think it's pretty clear that Git has emerged as the "winning" technology, in
terms of mind-share, adoption, excitement, etc.  I run into new Git projects
constantly.  Several prominent Haskell projects (such as bytestring) just
switched from Darcs to Git in order to attract contributors.  Whereas I
encounter Mercurial and Bazaar, well, never.  Darcs a few times, due to the
Haskell community, but only ever there.

John

Eli Zaretskii | 2 Apr 21:14 2013
Picon

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

> From: "John Wiegley" <johnw <at> newartisans.com>
> Date: Mon, 01 Apr 2013 12:47:34 -0500
> 
> The reason (personally) why I do not want Mercurial to become the Emacs VCS is
> for the same reason I don't like bzr: Because it's not used by a *single*
> project whose VCS I track or contribute to.  I don't know the UI, and have
> never had any reason to know the UI.  I'm not even sure I have Mercurial
> installed!
> 
> Meanwhile, the number of Git repositories on my machine today: 457.

Are you saying that the project should choose its VCS because you
personally use it exclusively, or because you personally don't want to
learn a new UI?  That'd be absurd.  What about the hours _I_ invested
in learning bzr -- doesn't that count?  What about the collective
hours invested in incorporating bzr into our workflows and
pretest/release cycles, and into writing admin/notes and bzrmerge.el?
do we just throw that away and start from scratch?  Is your personal
happiness really worth that much to justify all that waste?

Selecting a VCS is a prerogative of the head maintainers.  Sometimes
they will ask contributors for opinions, sometimes they won't (I
participate in projects that did either of these).  The only thing
that matters is that the selected VCS supports the platforms that the
project cares about, and that it is reasonably efficient.  Whether
J.R. Hacker is or isn't happy about the choice is not really relevant.
I know, because a couple of projects to which I contribute switched to
git, and no one asked me whether I was happy (nor should they).

Sorry for being blunt, but this is just waaaaay out of line, even for
(Continue reading)

Karl Fogel | 2 Apr 21:28 2013

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

Eli Zaretskii <eliz <at> gnu.org> writes:
>Are you saying that the project should choose its VCS because you
>personally use it exclusively, or because you personally don't want to
>learn a new UI?  That'd be absurd.  What about the hours _I_ invested
>in learning bzr -- doesn't that count?  What about the collective
>hours invested in incorporating bzr into our workflows and
>pretest/release cycles, and into writing admin/notes and bzrmerge.el?
>do we just throw that away and start from scratch?  Is your personal
>happiness really worth that much to justify all that waste?
>
>Selecting a VCS is a prerogative of the head maintainers.  Sometimes
>they will ask contributors for opinions, sometimes they won't (I
>participate in projects that did either of these).  The only thing
>that matters is that the selected VCS supports the platforms that the
>project cares about, and that it is reasonably efficient.  Whether
>J.R. Hacker is or isn't happy about the choice is not really relevant.
>I know, because a couple of projects to which I contribute switched to
>git, and no one asked me whether I was happy (nor should they).
>
>Sorry for being blunt, but this is just waaaaay out of line, even for
>this thread.

I think he was just offering himself as a data point (and perhaps
encouraging others to do the same inspection).  My numbers are similar
to John's, FWIW.

Eli Zaretskii | 2 Apr 21:36 2013
Picon

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

> From: Karl Fogel <kfogel <at> red-bean.com>
> Date: Tue, 02 Apr 2013 14:28:32 -0500
> Cc: John Wiegley <johnw <at> newartisans.com>, emacs-devel <at> gnu.org
> 
> I think he was just offering himself as a data point (and perhaps
> encouraging others to do the same inspection).  My numbers are similar
> to John's, FWIW.

Well, mine differ (obviously).

John Wiegley | 4 Apr 19:44 2013

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

>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:

> Are you saying that the project should choose its VCS because you personally
> use it exclusively, or because you personally don't want to learn a new UI?

Hi Eli,

I was giving my personal reasons for starting up this thread.  What's best for
the project is a separate matter, and if you ask me I think it should be put
to a vote among those of us who contribute to Emacs' development.

As a data point: if Emacs does decide on Git, I'll become a more active
contributor again; if it doesn't, I have other things to do.  Bzr/Mercurial is
enough of a "joy-stealing" barrier that -- like now -- I would not be
interested in submitting my work upstream.  And this same situation is true
for some others as well, as evidenced by voices on this mailing list.

If that counts for little, then OK, it counts for little.  But there is room
for expressing preferences here, since this is a volunteer effort, and not a
faceless enterprise.

With respect,
  John

Eli Zaretskii | 4 Apr 20:16 2013
Picon

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

> From: John Wiegley <johnw <at> newartisans.com>
> Date: Thu, 04 Apr 2013 12:44:43 -0500
> 
> As a data point: if Emacs does decide on Git, I'll become a more active
> contributor again; if it doesn't, I have other things to do.  Bzr/Mercurial is
> enough of a "joy-stealing" barrier that -- like now -- I would not be
> interested in submitting my work upstream.  And this same situation is true
> for some others as well, as evidenced by voices on this mailing list.

I'm very sad to hear that, because I think it is improper for
contributors to put up such an ultimatum for a project.  I hope that
people who contribute to Emacs (and any other project) are first and
foremost interested in advancing the project, and any other
considerations are secondary.

At least that's how I reacted when Gawk and Make switched to Git: I
gnashed my teeth and adapted.  I hope so will you.

joakim | 4 Apr 20:44 2013
Picon

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

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: John Wiegley <johnw <at> newartisans.com>
>> Date: Thu, 04 Apr 2013 12:44:43 -0500
>> 
>> As a data point: if Emacs does decide on Git, I'll become a more active
>> contributor again; if it doesn't, I have other things to do.  Bzr/Mercurial is
>> enough of a "joy-stealing" barrier that -- like now -- I would not be
>> interested in submitting my work upstream.  And this same situation is true
>> for some others as well, as evidenced by voices on this mailing list.
>
> I'm very sad to hear that, because I think it is improper for
> contributors to put up such an ultimatum for a project.  I hope that
> people who contribute to Emacs (and any other project) are first and
> foremost interested in advancing the project, and any other
> considerations are secondary.
>
> At least that's how I reacted when Gawk and Make switched to Git: I
> gnashed my teeth and adapted.  I hope so will you.

I think the debate could be made more constructive, if bzr upstream
would show some life signs and accept the bzr-fastimport patches
floating around, and other patches. Then people could use whatever local
tooling they like.

--

-- 
Joakim Verona

John Wiegley | 4 Apr 21:15 2013

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

>>>>> joakim  <joakim <at> verona.se> writes:

> I think the debate could be made more constructive, if bzr upstream would
> show some life signs and accept the bzr-fastimport patches floating around,
> and other patches. Then people could use whatever local tooling they like.

Yes, this really would be the best of all worlds.  I care so much more about
the front-end experience than I do about how data is stored on the GNU
servers.

John

Eli Zaretskii | 4 Apr 22:50 2013
Picon

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

> From: John Wiegley <johnw <at> newartisans.com>
> Date: Thu, 04 Apr 2013 14:15:28 -0500
> 
> >>>>> joakim  <joakim <at> verona.se> writes:
> 
> > I think the debate could be made more constructive, if bzr upstream would
> > show some life signs and accept the bzr-fastimport patches floating around,
> > and other patches. Then people could use whatever local tooling they like.
> 
> Yes, this really would be the best of all worlds.  I care so much more about
> the front-end experience than I do about how data is stored on the GNU
> servers.

I agree.  Let's hope that Richard will succeed in finding a responsive
maintainer to do that, and much more.

Sam Steingold | 4 Apr 20:57 2013
Picon

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

> * Eli Zaretskii <ryvm <at> tah.bet> [2013-04-04 21:16:46 +0300]:
>
>> From: John Wiegley <johnw <at> newartisans.com>
>> Date: Thu, 04 Apr 2013 12:44:43 -0500
>> 
>> As a data point: if Emacs does decide on Git, I'll become a more active
>> contributor again; if it doesn't, I have other things to do.  Bzr/Mercurial is
>> enough of a "joy-stealing" barrier that -- like now -- I would not be
>> interested in submitting my work upstream.  And this same situation is true
>> for some others as well, as evidenced by voices on this mailing list.
>
> I'm very sad to hear that, because I think it is improper for
> contributors to put up such an ultimatum for a project.

This is not an ultimatum, at least it does not look like that to me.

> I hope that people who contribute to Emacs (and any other project) are
> first and foremost interested in advancing the project, and any other
> considerations are secondary.

This is a very simplistic view, IMHO.

Many people contribute because they have a personal itch to scratch.
If scratching the itch involves an "unpleasant experience" (struggling
with an unfamiliar VCS, paperwork - you name it), some people would
forego the scratching.

Many people contribute to several projects and have to balance their
time between them, and if contributing to one project is unpleasant for
some reason, they may dedicate less of their time to it.
(Continue reading)

Eli Zaretskii | 4 Apr 22:48 2013
Picon

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

> From: Sam Steingold <sds <at> gnu.org>
> Date: Thu, 04 Apr 2013 14:57:03 -0400
> 
> > I hope that people who contribute to Emacs (and any other project) are
> > first and foremost interested in advancing the project, and any other
> > considerations are secondary.
> 
> This is a very simplistic view, IMHO.

You've got to see the wood, trees notwithstanding.

> Many people contribute because they have a personal itch to scratch.
> If scratching the itch involves an "unpleasant experience" (struggling
> with an unfamiliar VCS, paperwork - you name it), some people would
> forego the scratching.

Exactly what I have with Gawk and Make.  But the itch wins, as I think
it should.

> Many people contribute to several projects and have to balance their
> time between them, and if contributing to one project is unpleasant for
> some reason, they may dedicate less of their time to it.

Yes, that's what I do, too.

With Emacs available through git for a long time, and patches welcome
from people who for some reason cannot commit themselves, I don't see
too many reasons for unpleasant experience in the case in point.

(Continue reading)

Bastien | 5 Apr 06:34 2013
Picon

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

Sam Steingold <sds <at> gnu.org> writes:

> Many people contribute to several projects and have to balance their
> time between them, and if contributing to one project is unpleasant for
> some reason, they may dedicate less of their time to it.

Even if I'm a long-standing supporter of using Git instead of bzr,
I believe a nice atmosphere on a mailing list and a good reactivity
of core maintainers are far more important than the dVCS we use.

Let's not forget that we do enjoy both on emacs-devel!

--

-- 
 Bastien

Xue Fuqiao | 5 Apr 12:46 2013
Picon

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

On Fri, 05 Apr 2013 06:34:56 +0200
Bastien <bzg <at> gnu.org> wrote:

> Even if I'm a long-standing supporter of using Git instead of bzr,
> I believe a nice atmosphere on a mailing list and a good reactivity
> of core maintainers are far more important than the dVCS we use.

A great +1.

--

-- 
Xue Fuqiao
http://www.gnu.org/software/emacs/

Barry Warsaw | 5 Apr 17:37 2013

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

>Many people contribute to several projects and have to balance their
>time between them, and if contributing to one project is unpleasant for
>some reason, they may dedicate less of their time to it.

This isn't personal, but I generally find such complaints about vcs
unpleasantness as a barrier to contribution to be a red herring.  It's a fact
of life in today's FLOSS world that we have a universe of vcses (distributed
or otherwise) to contend with: git, hg, bzr, svn, cvs are all out there
holding the source code for projects I care about.  Add to that, the equally
wide variety of code hosting services and workflows those projects have
adopted.

If I have a nasty itch to scratch, I have to just suck it up and learn the
basics of all that in order to provide a patch or branch that is valuable
enough to upstream that they'll spend their very limited resources shepherding
my patch to successful landing.  Frankly, it's not all that hard to learn (or
re-learn each time ;) the basics of any of the vcses, and it's usually just a
very small part of the investment to contribute to a project.

I'm *much* more concerned about the workflow, efficiency, and comfort of the
project leaders, the people who are doing the bulk of the development work,
reviewing and accepting branches and patches, making releases, etc.  If
choosing CVS and Bugzilla makes their lives easier, go for it!  I can adapt.
And I should adapt because the work they put in far outweighs the work I put
in on the project.

In some ways, it's like the choice of programming language.  Okay, I don't
love Perl or C++ but if that's the project's choice, and I want to contribute
in ways big or small, I learn enough to do so.  But it seems unfair for me to
say "if you just ported everything to Python, I'd be much more willing to
(Continue reading)

Jambunathan K | 7 Apr 01:03 2013
Picon

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


Barry Warsaw <barry <at> python.org> writes:

> If I have a nasty itch to scratch, I have to just suck it up and learn the
> basics of all that in order to provide a patch or branch that is valuable
> enough to upstream

Before I could land my first patch in Orgmode, I had to pick up Emacs
Lisp, Git and also LibreOffice.  That is 3 barriers, right away.

My first patch to Emacs was a diff against a file which was downloaded
from Loggerhead.

> I'm *much* more concerned about the workflow, efficiency, and comfort of the
> project leaders, the people who are doing the bulk of the development work,
> reviewing and accepting branches and patches, making releases, etc.

Well said.

> OTOH, the sentiments above do count, in the sense that as a contributor, you
> are volunteering your time too.  Maybe you choose to only contribute to
> projects that use Ruby on Mercurial and only run on Debian ARM devices.
> As a volunteer, that's your prerogative.

Volunteers have the right to place conditions under which they can
contribute, particularly if the volunteer is a regular and is of some
standing and has reasons to believe that his views will atleast be read.

It is OK to lobby for one's and one's kin's interest or act in manner
that is political and wield both carrot and a stick.  There will be less
(Continue reading)

Stefan Monnier | 7 Apr 03:09 2013
Picon

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

> in ways big or small, I learn enough to do so.  But it seems unfair for me to
> say "if you just ported everything to Python, I'd be much more willing to
> contribute".

Whether we like it or not, using popular tools and languages does have
its benefit in terms of broadening the base of potential contributors.

Emacs tends to not be very good on this front, but makes up for it by
making it unusually easy to jump from "the thing I want to change" to
"the code I need to change".

So, it might be the case that using Git would bring us
more contributions.  I don't think this is a big enough consideration to
justify a move, but I think it's worth keeping it in mind, when other
considerations push us to such a move.

        Stefan "who contributed to Svn and Git based projects, using
                bzr-svn and bzr-git, respectively"

Xue Fuqiao | 7 Apr 07:22 2013
Picon

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

On Sat, 06 Apr 2013 21:09:03 -0400
Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

> So, it might be the case that using Git would bring us more
> contributions.  I don't think this is a big enough consideration to
> justify a move, but I think it's worth keeping it in mind, when other
> considerations push us to such a move.

Will the maintenance status of Bazaar be the "other considerations"?

--

-- 
Xue Fuqiao
http://www.gnu.org/software/emacs/

Stephen Leake | 5 Apr 01:08 2013
Picon

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

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: John Wiegley <johnw <at> newartisans.com>
>> Date: Thu, 04 Apr 2013 12:44:43 -0500
>> 
>> As a data point: if Emacs does decide on Git, I'll become a more active
>> contributor again; if it doesn't, I have other things to do.  Bzr/Mercurial is
>> enough of a "joy-stealing" barrier that -- like now -- I would not be
>> interested in submitting my work upstream.  And this same situation is true
>> for some others as well, as evidenced by voices on this mailing list.
>
> I'm very sad to hear that, because I think it is improper for
> contributors to put up such an ultimatum for a project.  

It was not expressed as an ultimatum (read "threat"), just as a fact.

People have limited time; if the tools use enough time to notice, it's a
problem.

>I hope that
> people who contribute to Emacs (and any other project) are first and
> foremost interested in advancing the project, and any other
> considerations are secondary.

Secondary can still be important enough to matter in a choice of which
important project to contribute to.

> At least that's how I reacted when Gawk and Make switched to Git: I
> gnashed my teeth and adapted.  I hope so will you.

(Continue reading)

Daniel Colascione | 5 Apr 01:58 2013

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

On 4/4/2013 4:08 PM, Stephen Leake wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>>> From: John Wiegley <johnw <at> newartisans.com>
>>> Date: Thu, 04 Apr 2013 12:44:43 -0500
>>>
>>> As a data point: if Emacs does decide on Git, I'll become a more active
>>> contributor again; if it doesn't, I have other things to do.  Bzr/Mercurial is
>>> enough of a "joy-stealing" barrier that -- like now -- I would not be
>>> interested in submitting my work upstream.  And this same situation is true
>>> for some others as well, as evidenced by voices on this mailing list.
>>
>> I'm very sad to hear that, because I think it is improper for
>> contributors to put up such an ultimatum for a project.  
> 
> It was not expressed as an ultimatum (read "threat"), just as a fact.

I'm also having a very difficutl time reading John's post as an ultimatum. I'd
no different from saying "I'm less likely to contribute to Emacs if it's
rewritten in COBOL". We're all volunteers here, and while at work, I'm paid to
overcome organizational friction, there's no such countervailing force here. We
all work on Emacs because we want to. VCS choice can reduce that desire, and
while that's unfortunate, it's a fact of the world we inhabit.

I see very little justification for choosing anything other than git --- it's
high quality free software that's well on its way to becoming ubiquitous in the
development community. There is no moral, financial, or organizational penalty
to choosing it, and there are reams of advantages. Our choosing git would
advance the cause of free software as much as any other option and would greatly
streamline Emacs development.
(Continue reading)

Stephen J. Turnbull | 5 Apr 03:13 2013
Picon

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

Daniel Colascione writes:

 > As I see it, the only other viable candidate is Mercurial, which,
 > while being high-quality, actively-developed free software, lacks
 > the user base of git.  If Mercurial and git are equivalent of
 > technical and ethical grounds,

Evidently, they're not.  Technically, people care about UI, and many
people hate git's.  Ethically, git uses copyleft but most of its
developers are pretty clearly firmly in the open source camp (vs. free
software), and some of its most popular associated tools (GitHub) use
non-free code without apology (although it seems that a lot of people
associated with Linux kernel development don't exactly appreciate the
attitude of GitHub in many respects).

You may not believe either of those outweigh the economic advantages
of git, but you should acknowledge those differences of opinion as
objective facts.

Wojciech Meyer | 7 Apr 05:11 2013
Picon

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

"Stephen J. Turnbull" <stephen <at> xemacs.org> writes:

> Daniel Colascione writes:
>
>  > As I see it, the only other viable candidate is Mercurial, which,
>  > while being high-quality, actively-developed free software, lacks
>  > the user base of git.  If Mercurial and git are equivalent of
>  > technical and ethical grounds,
>
> Evidently, they're not.  Technically, people care about UI, and many
> people hate git's.  Ethically, git uses copyleft but most of its
> developers are pretty clearly firmly in the open source camp (vs. free
> software), and some of its most popular associated tools (GitHub) use
> non-free code without apology (although it seems that a lot of people
> associated with Linux kernel development don't exactly appreciate the
> attitude of GitHub in many respects).
>
> You may not believe either of those outweigh the economic advantages
> of git, but you should acknowledge those differences of opinion as
> objective facts.

In general, the popularity of tools in my opinion is one of the key
factors how much momentum the project will gain. There are of course
other ways of gaining that momentum, and they usually require a bit less
of consideration and work. Looking at improvements to the documentation
or wiki pages, it might be the right solution for the projects that
can't easily switch to some other technology like Emacs, where it's just
does not look feasible. It takes a bit of time, and people understanding
and willing to do this. Emacs has a great wiki, and possibly the same
could be done for the developers. Surely people tried to document bzr on
(Continue reading)

Karl Fogel | 5 Apr 16:55 2013

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

Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: John Wiegley <johnw <at> newartisans.com>
>> As a data point: if Emacs does decide on Git, I'll become a more
>> active contributor again; if it doesn't, I have other things to do.
>> Bzr/Mercurial is enough of a "joy-stealing" barrier that -- like now
>> -- I would not be interested in submitting my work upstream.  And
>> this same situation is true for some others as well, as evidenced by
>> voices on this mailing list.
>
>I'm very sad to hear that, because I think it is improper for
>contributors to put up such an ultimatum for a project.  I hope that
>people who contribute to Emacs (and any other project) are first and
>foremost interested in advancing the project, and any other
>considerations are secondary.

No ultimatum here; John made a statement about a development barrier.

If Emacs stored its master repository on punch cards and the only way to
contribute were to send in new cards by snail mail, some developers
would post saying "I'd like to be more involved, but the snail mail
thing is joy-stealing barrier for me."

Obviously that's a contrived example, but it is different from what John
said only in degree.

>At least that's how I reacted when Gawk and Make switched to Git: I
>gnashed my teeth and adapted.  I hope so will you.

All developers do cost-benefit analysis when deciding where to spend
their time.  The fact that your calculus differs from John's doesn't
(Continue reading)

Eli Zaretskii | 5 Apr 17:14 2013
Picon

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

> From: Karl Fogel <kfogel <at> red-bean.com>
> Cc: John Wiegley <johnw <at> newartisans.com>,  emacs-devel <at> gnu.org
> Date: Fri, 05 Apr 2013 10:55:26 -0400
> 
> sometimes, you might mail a project and say "If your build process
> [or whatever] were easier, I'd be more likely to contribute."

No, never.

Lennart Borgman | 5 Apr 17:21 2013
Picon

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

On Fri, Apr 5, 2013 at 5:14 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Karl Fogel <kfogel <at> red-bean.com>
>> Cc: John Wiegley <johnw <at> newartisans.com>,  emacs-devel <at> gnu.org
>> Date: Fri, 05 Apr 2013 10:55:26 -0400
>>
>> sometimes, you might mail a project and say "If your build process
>> [or whatever] were easier, I'd be more likely to contribute."
>
> No, never.

Since it is a matter of how much time you have of course this matters.

Julien Danjou | 5 Apr 11:57 2013

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

On Thu, Apr 04 2013, Eli Zaretskii wrote:

> I'm very sad to hear that, because I think it is improper for
> contributors to put up such an ultimatum for a project.  I hope that
> people who contribute to Emacs (and any other project) are first and
> foremost interested in advancing the project, and any other
> considerations are secondary.

Eli, this is not an ultimatum, this is a fact.
I feel like John about this. Contributing to Emacs by using bzr requires
a larger amount of effort for me than to any other project, and I often
postponed my contributions because of that.

--

-- 
Julien Danjou
# Free Software hacker # freelance consultant
# http://julien.danjou.info
Pascal J. Bourguignon | 3 Apr 00:00 2013
Face

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

"John Wiegley" <johnw <at> newartisans.com> writes:

>>>>>> Giorgos Keramidas <gkeramidas <at> gmail.com> writes:
>
>> Mercurial is used for Python itself (and quite a few other large projects),
>> so its longevity is not really a very difficult question.  It will be here
>> for at least as long as Python, which Bazaar also uses.
>
> The reason (personally) why I do not want Mercurial to become the Emacs VCS is
> for the same reason I don't like bzr: Because it's not used by a *single*
> project whose VCS I track or contribute to.  I don't know the UI, and have
> never had any reason to know the UI.  I'm not even sure I have Mercurial
> installed!
>
> Meanwhile, the number of Git repositories on my machine today: 457.
>
> I think it's pretty clear that Git has emerged as the "winning" technology, in
> terms of mind-share, adoption, excitement, etc.  I run into new Git projects
> constantly.  Several prominent Haskell projects (such as bytestring) just
> switched from Darcs to Git in order to attract contributors.  Whereas I
> encounter Mercurial and Bazaar, well, never.  Darcs a few times, due to the
> Haskell community, but only ever there.

If you go there, the marketshare or mindshare of emacs is even less than
that of mercurial.  You can stop using emacs right now, and switch to
vim or SublimeText.

--

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.
(Continue reading)

Stephen J. Turnbull | 27 Mar 09:55 2013
Picon

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

Michael Welsh Duggan writes:

 > I see these Git versus Bazaar arguments pop up every now and then on
 > this forum.  I must admit my experience with Git has been better than
 > that with Bazaar, but I have to ask, why isn't Mercurial being
 > considered?

Nobody in the community is using it to develop Emacs, would be the
reason I expect.

Mercurial is perfectly serviceable, XEmacs and Python both use it.
However, it really isn't as powerful or coherent as git, and the DAGs
it creates tend to be rather ugly unless you have a standard
project-wide workflow.  The lack of a good colocated branch story[1]
hurts in many workflows (as indeed it does in Bazaar). Nobody does
submodules well yet, but I'll bet git gets there first because git's
implementation is such a natural extension of Linus's original model.

Despite the constant criticism of git's command-line UI[2], IMO it's a
red herring for Emacs use[3].  In git's favor, git has a powerful
(though incomplete in some respects[4]) model of version control,
consistently applies it, and exposes its full power to all users.
Perhaps that resembles an editor you know?  Not to mention that the
operation of "commit", basic to all version control, is implemented by
adding a link to the head of a singly-linked list.  Does that resemble
a programming language you've heard of?[5]

Now it's true that perhaps the majority of Emacs developers want a VCS
that just stays out of their way.  Bazaar and Mercurial are better
choices for that, it seems, but only if you restrict yourself to the
(Continue reading)

John Wiegley | 27 Mar 15:10 2013

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

>>>>> Michael Welsh Duggan <mwd <at> md5i.com> writes:

> I see these Git versus Bazaar arguments pop up every now and then on this
> forum.  I must admit my experience with Git has been better than that with
> Bazaar, but I have to ask, why isn't Mercurial being considered?  From a
> license perspective, Mercurial is GPLv2+, while Git is GPLv2.  I found
> Mercurial's command-line UI much easier to learn and understand than Git,
> and I believe the two are fairly comparable in power.

I love to debate technical merits as much as the next guy, but that really
wasn't the motive for my opening post.  What we have to consider are issues
affecting Emacs development as a whole -- not how well structured one DVCS'
DAG is over another, or whether one license is stronger than another.

Here is a brief list of things I believe we want in a VCS for Emacs:

 - A stable VCS, with an active community, where bugs get fixed in a timely
   fashion.

 - Something fast, efficient, and with good performance "over the wire".

 - A system people stand more chance of already knowing, so there is little
   inertia to prevent them from becoming active Emacs contributors.

   There are some of us (present company included) who use Bazaar for nothing
   else outside of Emacs, but who do use Git on a daily basis for many other
   projects.  It would be nice, at least from a personal standpoint, if I
   could leverage that experience.

 - As much of a consistent ecosystem among various areas of Emacs development
(Continue reading)

Romain Francoise | 27 Mar 17:54 2013

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

"John Wiegley" <johnw <at> newartisans.com> writes:

> I think Git presents us with a pretty good answer to each of these
> points, in terms of Emacs development.

You can work on Emacs using Git today, the Git mirror is an accurate
conversion of what's in Bazaar and is updated at a reasonable frequency.
When I did the ACL stuff last year I had everything in Git and only used
Bazaar once, to install my changes (after several rounds of review).

I hate to play devil's advocate, I'm all for a switch to Git. But at least
from my experience, having the code in Bazaar is only a minor
inconvenience. I imagine that the same would apply to a majority of
potential contributors if we just encouraged people to use the Git mirror
instead of Bazaar.

Jordi Gutiérrez Hermoso | 27 Mar 15:52 2013

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

On 27 March 2013 00:15, Michael Welsh Duggan <mwd <at> md5i.com> wrote:
> "John Wiegley" <johnw <at> newartisans.com> writes:
>
>> We have often debated the merits of Git vs. Bazaar, and which one the GNU
>> project should use for Emacs development.  I think now is an appropriate time
>> to revisit this decision.
>
> I see these Git versus Bazaar arguments pop up every now and then on
> this forum.  I must admit my experience with Git has been better than
> that with Bazaar, but I have to ask, why isn't Mercurial being
> considered?  From a license perspective, Mercurial is GPLv2+, while Git
> is GPLv2.  I found Mercurial's command-line UI much easier to learn and
> understand than Git, and I believe the two are fairly comparable in
> power.

We are happily using Mercurial in GNU Octave, and I heartily recommend
it to anyone, especially to GNU. The Mercurial community is dedicated
to free software as evidenced by the GPLv2 *or later* that hg has and
git doesn't, as well as things such as

    http://selenic.com/pipermail/mercurial/2011-March/037593.html

Half of the things in git's wishlist here are already in Mercurial:

    https://github.com/peff/git/wiki/SoC-2012-Ideas

Namely: git log --follow support, improved parallelism (in hg 2.6,
nearing release), git instaweb --serve, and "published" and "secret"
commits. Mercurial is overall comparable in features to git, of
comparable speed, and sometimes faster, e.g. compare the cloning time
(Continue reading)

Carsten Dominik | 27 Mar 08:53 2013
Picon

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


On 26 mrt. 2013, at 20:38, John Wiegley <johnw <at> newartisans.com> wrote:

> Hello all,
> 
> We have often debated the merits of Git vs. Bazaar, and which one the GNU
> project should use for Emacs development.  I think now is an appropriate time
> to revisit this decision.
> 
> My main reason for bringing this up again is that Bazaar development has
> effectively stalled.  There are major bugs which have been in their
> bug-tracker for years now -- bugs affecting Emacs development, such as the
> ELPA repository -- whach have been ignored all this time.  There are also
> other factors, but this one alone is significant enough that I think it
> justifies us switching over to Git all by itself.
> 
> So, to Richard as the undisputed Czar of all things Emacs: can we now, pretty
> please, switch to Git? :)  I'm happy to coordinate whatever resources it takes
> to make a full and faithful conversion from Bzr happen as soon as possible.

For what it is worth,  I believe that the Org-mode community
would wholeheartedly support such a move, it would simplify things
for us enormously.

With kind regards

- Carsten Dominik

Julien Danjou | 27 Mar 10:09 2013

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

On Tue, Mar 26 2013, John Wiegley wrote:

> We have often debated the merits of Git vs. Bazaar, and which one the GNU
> project should use for Emacs development.  I think now is an appropriate time
> to revisit this decision.
>
> My main reason for bringing this up again is that Bazaar development has
> effectively stalled.  There are major bugs which have been in their
> bug-tracker for years now -- bugs affecting Emacs development, such as the
> ELPA repository -- whach have been ignored all this time.  There are also
> other factors, but this one alone is significant enough that I think it
> justifies us switching over to Git all by itself.

I strongly support this initiative.

--

-- 
Julien Danjou
/* Free Software hacker * freelance consultant
   http://julien.danjou.info */
Ted Zlatanov | 27 Mar 10:56 2013
X-Face

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

On Wed, 27 Mar 2013 10:09:34 +0100 Julien Danjou <julien <at> danjou.info> wrote: 

JD> On Tue, Mar 26 2013, John Wiegley wrote:
>> We have often debated the merits of Git vs. Bazaar, and which one the GNU
>> project should use for Emacs development.  I think now is an appropriate time
>> to revisit this decision.

JD> I strongly support this initiative.

I support it, likewise.  We've had technical developments since Bazaar
was chosen:

- magit.el has matured; VCS mode has improved Git support

- Git credential helpers let the user get and store authentication
  tokens to external facilities like the Mac OS X or W32 keychain (I
  wrote one to talk to a netrc file with or without GPG encryption,
  allowing Git and Emacs' auth-source.el to share the same netrc file)

- I am not aware of any projects choosing Bazaar for any reason,
  technical or not, since RMS' decision.

- the Gnus project has a person dedicated to Bazaar-Git bidirectional
  synchronization; it is a very demanding task for the rest of us.

Ted

David Engster | 27 Mar 11:36 2013
Picon

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

Ted Zlatanov writes:
> - I am not aware of any projects choosing Bazaar for any reason,
>   technical or not, since RMS' decision.

CEDET.

OK, not a great data point, I admit that. :-)

I think bzr is good enough (and much, *much* better than during the time
Emacs switched to it), and I could live with bzr being in maintenance
mode if it was actually rock-solid. However, next to the obvious ELPA
branch bug, it also seems the conflict handling during merges is still
problematic. I hit such a bug, and it would have been a showstopper if
some nice guy from the bzr mailing list hadn't shown me a workaround:

https://lists.ubuntu.com/archives/bazaar/2012q3/075253.html

What also worries me is that our CEDET repository seems to have become
nonconvertible during the merges, and development on the 'Fast Import'
plugin seems to have stalled as well, so I don't think bugs like
https://bugs.launchpad.net/bzr-fastimport/+bug/1057534 will ever get
fixed. Therefore, I'm not sure we could even switch to git if we wanted
to. It is also very unfortunate that for this reason we cannot provide a
git mirror, which I consider to be important for attracting developers
in the first place.

> - the Gnus project has a person dedicated to Bazaar-Git bidirectional
>   synchronization; it is a very demanding task for the rest of us.

Well, I don't believe that git will make cross-project merges easier, at
(Continue reading)

Ted Zlatanov | 27 Mar 13:51 2013
X-Face

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

On Wed, 27 Mar 2013 11:36:44 +0100 David Engster <deng <at> randomsample.de> wrote: 

DE> Ted Zlatanov writes:

>> - the Gnus project has a person dedicated to Bazaar-Git bidirectional
>> synchronization; it is a very demanding task for the rest of us.

DE> Well, I don't believe that git will make cross-project merges easier, at
DE> least not until someone shows me how (and don't just say "submodules",
DE> please ;-) ).

The challenge for me is matching Bazaar and Git commits and
synchronizing them because I don't know Bazaar and don't use it for any
other purpose.  I am pretty sure that's the case for the rest of the
Gnus contributors (Julien is one of them; Lars doesn't like Bazaar much
IIRC; we chose Git over Bazaar years ago and have not regretted it).

For this specific case, `git filter-branch' will probably be used to
rewrite paths the way you describe, but that's a technical detail.
Git-Git sync is just much easier logistically.

Ted

Julien Danjou | 27 Mar 13:55 2013

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

On Wed, Mar 27 2013, David Engster wrote:

> Well, I don't believe that git will make cross-project merges easier, at
> least not until someone shows me how (and don't just say "submodules",
> please ;-) ).

I'm pretty sure it does make this easier:

    http://git-scm.com/book/en/Git-Tools-Subtree-Merging

--

-- 
Julien Danjou
# Free Software hacker # freelance consultant
# http://julien.danjou.info
Stefan Monnier | 27 Mar 14:39 2013
Picon

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

>> Well, I don't believe that git will make cross-project merges easier, at
>> least not until someone shows me how (and don't just say "submodules",
>> please ;-) ).
> I'm pretty sure it does make this easier:
>     http://git-scm.com/book/en/Git-Tools-Subtree-Merging

The core of the problem is bidirectional merging.  AFAIK none of the
current DVCS have an answer for that.  Subtree merging is nice, but it's
still unidirectional.

For bidirectional merging, you end up having to do some of the work
outside of the DVCS proper, in which case having Bazaar on one side and
Git on the other doesn't make much difference.  Especially since you can
use things like bzr-git to translate a branch from one system to
the other.

        Stefan

David Engster | 27 Mar 14:58 2013
Picon

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

Stefan Monnier writes:
>>> Well, I don't believe that git will make cross-project merges easier, at
>>> least not until someone shows me how (and don't just say "submodules",
>>> please ;-) ).
>> I'm pretty sure it does make this easier:
>>     http://git-scm.com/book/en/Git-Tools-Subtree-Merging
>
> The core of the problem is bidirectional merging.  AFAIK none of the
> current DVCS have an answer for that.  Subtree merging is nice, but it's
> still unidirectional.

Exactly. The other problem is this little "one of the projects maps to a
subdirectory of the other one", which AFAIK must be taken literally.

> For bidirectional merging, you end up having to do some of the work
> outside of the DVCS proper, in which case having Bazaar on one side and
> Git on the other doesn't make much difference.  Especially since you can
> use things like bzr-git to translate a branch from one system to
> the other.

Let me also point to

http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/

which is pretty magic (and *almost* manages to convert the CEDET repo).

But in the end, you just do the 'diff | patch' game, no matter which
VCS.

-David
(Continue reading)

Stephen Leake | 28 Mar 00:13 2013
Picon

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

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> Well, I don't believe that git will make cross-project merges easier, at
>>> least not until someone shows me how (and don't just say "submodules",
>>> please ;-) ).
>> I'm pretty sure it does make this easier:
>>     http://git-scm.com/book/en/Git-Tools-Subtree-Merging
>
> The core of the problem is bidirectional merging.  

If I understand what you mean by "bidirectional merging", then monotone
handles it nicely (http://www.monotone.ca/).

I use monotone for all my projects, and merge back and forth between
branches all the time.

--

-- 
-- Stephe

Stephen Leake | 28 Mar 00:16 2013
Picon

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

Stephen Leake <stephen_leake <at> member.fsf.org> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>>>> Well, I don't believe that git will make cross-project merges easier, at
>>>> least not until someone shows me how (and don't just say "submodules",
>>>> please ;-) ).
>>> I'm pretty sure it does make this easier:
>>>     http://git-scm.com/book/en/Git-Tools-Subtree-Merging
>>
>> The core of the problem is bidirectional merging.  
>
> If I understand what you mean by "bidirectional merging", then monotone
> handles it nicely (http://www.monotone.ca/).
>
> I use monotone for all my projects, and merge back and forth between
> branches all the time.

I suspect the key feature that makes it work is the conflict resolution
tools in monotone;
http://www.monotone.ca/docs/Merge-Conflicts.html#Merge-Conflicts

I worked hard to make that flow nicely, and also to make the Emacs front
end for it flow nicely
(http://stephe-leake.org/emacs/ada-mode/dvc-intro.html)

But there's not a lot of support for monotone, certainly no company is
behind it, so it's probably not a good bet for a large long-term project.
--

-- 
-- Stephe
(Continue reading)

Stephen J. Turnbull | 28 Mar 04:26 2013
Picon

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

Stephen Leake writes:

 > If I understand what you mean by "bidirectional merging", then monotone
 > handles it nicely (http://www.monotone.ca/).
 >
 > I use monotone for all my projects, and merge back and forth between
 > branches all the time.

When you say "my", do you mean projects that mostly only you work on?
If so, you probably won't run into the problem, unless you're in the
habit of keeping several workspaces on a given branch and you don't
keep them current.  In a one-person, multibranch workflow, you will
typically see DAGs like this:

trunk  0--------A--B--C--D-- ...
        \         /    \
         \       /      \
branch    a--b--c--------d-- ...

and the nature of such workflows is that typically conflicts are
relatively few; you do different things in different branches.
Furthermore, at each merge point (<B> and <d>) there are exactly two
paths from the most recent common ancestor (<c> and <C>,
respectively), which helps to simplify analysis of the merge.

Multi-person, multi-branch workflows admit a nastier kind of geometry,
which the Bazaar developers call "criss-cross merges" for an obvious
reason:

trunk  0--------A--B--C--D--E----- ...
(Continue reading)

Stephen Leake | 28 Mar 09:37 2013
Picon

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

"Stephen J. Turnbull" <stephen <at> xemacs.org> writes:

> Stephen Leake writes:
>
>  > If I understand what you mean by "bidirectional merging", then monotone
>  > handles it nicely (http://www.monotone.ca/).
>  >
>  > I use monotone for all my projects, and merge back and forth between
>  > branches all the time.
>
> When you say "my", do you mean projects that mostly only you work on?

yes, or a small group (~ 5 people), with a well controlled branching
policy.

> If so, you probably won't run into the problem, unless you're in the
> habit of keeping several workspaces on a given branch and you don't
> keep them current.  

That we do; each release is a branch, and new work happens both on trunk
for major new features, and on the release branch for patches.
Eventually they get merged together.

> In a one-person, multibranch workflow, you will typically see DAGs
> like this:
>
> trunk  0--------A--B--C--D-- ...
>         \         /    \
>          \       /      \
> branch    a--b--c--------d-- ...
(Continue reading)

Andreas Schwab | 28 Mar 10:15 2013

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

Stephen Leake <stephen_leake <at> member.fsf.org> writes:

> is there a git command that indicates the workspace is in the middle
> of an interactive rebase?

git status

Andreas.

--

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

David Engster | 28 Mar 10:07 2013
Picon

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

Stephen J. Turnbull writes:
> Multi-person, multi-branch workflows admit a nastier kind of geometry,
> which the Bazaar developers call "criss-cross merges" for an obvious
> reason:

Yes, I get 'criss-cross merge' warnings all the time.

To hopefully make clear what a "cross-project merge" implies, here's my
current setup for the CEDET merge:

       /--to-emacs  <-|   --------------------->
      /        ^      |         diff|patch
     |         |      |
     |         |      |
CEDET ----trunk|    <-|                         Emacs trunk
     |                |
     |                |
      \               |         diff|patch
       \--from-emacs -|   <--------------------

CEDET->Emacs: This is actually fairly easy. The 'to-emacs' branch is a
subset of Emacs trunk, containing only the files from CEDET upstream,
but generated from CEDET 'trunk'. This also handily tracks necessary
renames (for instance, EIEIO is located under lisp/emacs-lisp in Emacs,
but in CEDET it is in lisp/eieio). So in theory, I can just merge
'trunk' into 'to-emacs', generate a diff from this merge, and apply it
to Emacs trunk. In practice however, I get a conflict for every file
that was changed in 'trunk' but does not exist in 'to-emacs' (and there
are many such files). Unfortunately, bzr cannot automatically deal with
this (is git able to do that?). But it's a minor issue, since I can
(Continue reading)

Christopher Schmidt | 28 Mar 10:55 2013

Abolishing ChangeLog files (was: On the subject of Git, Bazaar, and the future of Emacs development)

David Engster <deng <at> randomsample.de> writes:
> The most time consuming thing is fixing ChangeLogs (we don't have any
> in CEDET and generate them from commit logs).

I would like to suggest another change - how about removing ChangeLog
files from the development repository.  I think these files are
redundant to the commit log of the vc.

Removing the files from the repository would clean diffs and reduce
merge conflicts.  Considering distributed vc, a project's history cannot
be thought of as to be list of consecutive increments.

Distributions of Emacs could include ChangeLog files generated from the
vc commit log, of course.

Do I make sense?  Are there any drawbacks?

        Christopher

Thierry Volpiatto | 28 Mar 11:55 2013
Picon

Re: Abolishing ChangeLog files

Christopher Schmidt <christopher <at> ch.ristopher.com> writes:

> David Engster <deng <at> randomsample.de> writes:
>> The most time consuming thing is fixing ChangeLogs (we don't have any
>> in CEDET and generate them from commit logs).
>
> I would like to suggest another change - how about removing ChangeLog
> files from the development repository.  I think these files are
> redundant to the commit log of the vc.
>
> Removing the files from the repository would clean diffs and reduce
> merge conflicts.  Considering distributed vc, a project's history cannot
> be thought of as to be list of consecutive increments.
>
> Distributions of Emacs could include ChangeLog files generated from the
> vc commit log, of course.
>
> Do I make sense? 

YES!!!

> Are there any drawbacks?
>
>         Christopher
>
>

--

-- 
Thierry
Get my Gnupg key:
(Continue reading)

Richard Stallman | 28 Mar 19:58 2013
Picon
Picon

Re: Abolishing ChangeLog files

Emacs ChangeLog files are not redundant with VC change records.
We put different information in them.  At least, I do.
In the ChangeLog files I put lists of functions changed and how.
In the bzr log entry I explain the overall purpose of the change.

There are various good ways to store the important change information,
but this has been discussed before.  Let's not repeat.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Aidan Gauland | 28 Mar 21:09 2013
Picon

Re: Abolishing ChangeLog files

Richard Stallman <rms <at> gnu.org> writes:

> Emacs ChangeLog files are not redundant with VC change records.
> We put different information in them.  At least, I do.
> In the ChangeLog files I put lists of functions changed and how.
> In the bzr log entry I explain the overall purpose of the change.

I put both in the ChangeLog entry and then copy it to the commit log.  I
think the ChangeLog format (file list and overall summary) is great, and
I think we should use it in the commit logs.  (GNU Guile does this.)

--Aidan

Stefan Monnier | 28 Mar 22:00 2013
Picon

Re: Abolishing ChangeLog files

> Emacs ChangeLog files are not redundant with VC change records.
> We put different information in them.  At least, I do.
> In the ChangeLog files I put lists of functions changed and how.
> In the bzr log entry I explain the overall purpose of the change.

The rules we supposedly follow in Emacs's repository is to put a copy of
the ChangeLog entry in the commit record.  So the ChangeLog file
should be redundant.  If it's not, it's an error of the committer.

        Stefan

Richard Stallman | 29 Mar 04:47 2013
Picon
Picon

Re: Abolishing ChangeLog files

    The rules we supposedly follow in Emacs's repository is to put a copy of
    the ChangeLog entry in the commit record.  So the ChangeLog file
    should be redundant.  If it's not, it's an error of the committer.

I guess I have made that error in all my commits.

Why choose this approach, rather than the one I used?

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Paul Eggert | 29 Mar 07:36 2013

Re: Abolishing ChangeLog files

>      The rules we supposedly follow in Emacs's repository is to put a copy of
>      the ChangeLog entry in the commit record.  So the ChangeLog file
>      should be redundant.  If it's not, it's an error of the committer.
>
> I guess I have made that error in all my commits.
>
> Why choose this approach, rather than the one I used?

It's simpler and less confusing if the ChangeLog
equals the commit record.  When I'm reading a
ChangeLog, I often want to know the overall
purpose of the change, and it can be frustrating
when this information is omitted.  Conversely, when I'm
reading a sequence of commit records, it's
convenient to know all the functions and files
that got changed, for the same reason it's convenient
to know this when reading a ChangeLog.

For Emacs, I use typically use vc-dwim (a GNU program)
to check in changes.  vc-dwim computes the commit record
automatically from the ChangeLog changes.  So I
don't have to write commit records, and this saves
me time.

Many GNU programs these days compute ChangeLog
files automatically from the commit records, which
boils down to the same thing.  (vc-dwim also supports
this style of maintenance.)

(Continue reading)

Stefan Monnier | 29 Mar 21:57 2013
Picon

Re: Abolishing ChangeLog files

> Why choose this approach, rather than the one I used?

Because ChangeLog files are a pain in the youknowwhat (think spurious
conflicts) and we hope to get rid of them at some point.

        Stefan

Steve Youngs | 29 Mar 00:44 2013
X-Face
Face

Re: Abolishing ChangeLog files

* Richard Stallman <rms <at> gnu.org> writes:

  > Emacs ChangeLog files are not redundant with VC change records.
  > We put different information in them.  At least, I do.

You're probably a part of a quite small minority that does.  In most
cases where I have come across projects that use a modern SCM and
ChangeLog files they end up doing "double-accounting-logging" with a lot
of copy-pasting from one log to the other.

  > In the ChangeLog files I put lists of functions changed and how.
  > In the bzr log entry I explain the overall purpose of the change.

This may have made sense in the old days of limited featured VC's such
as RCS or CVS, but not anymore, not with today's tools.

Without looking it up I can't tell you what the very first change we
made to SXEmacs was, but I can say that eliminating the ChangeLog files
was one of the first.  Actually, I shouldn't say that the ChangeLog
files were "eliminated" because they still exist for the benefit of
people who use the tarball releases, but they are generated from the
SCM (tla in the beginning, git now).

  > There are various good ways to store the important change information,

Yes, but storing that information in two different places, even when
there isn't any overlap of info between the places, isn't one of them.
Why add a level of complexity, even a minor one like this, when you
don't need to?

(Continue reading)

Richard Stallman | 29 Mar 04:48 2013
Picon
Picon

Re: Abolishing ChangeLog files

      > There are various good ways to store the important change information,

    Yes, but storing that information in two different places, even when
    there isn't any overlap of info between the places, isn't one of them.

It is a fine method, which makes each kind of information convenient
for its purpose.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Steve Youngs | 29 Mar 09:02 2013
X-Face
Face

Re: Abolishing ChangeLog files

* Richard Stallman <rms <at> gnu.org> writes:

  >> There are various good ways to store the important change information,
  >     Yes, but storing that information in two different places, even when
  >     there isn't any overlap of info between the places, isn't one of them.

  > It is a fine method, which makes each kind of information convenient
  > for its purpose.

Seems to me that it would be a lot more convenient if the "what" and the
"why" of a change were in the same place.  That is where you are making
the split, ChangeLogs for the what and commit logs for the why?

The problem that your method alleviates, the doubling up of information,
simply doesn't exist when you are logging to a single place.

Your method does nothing to alleviate the problem of recurring conflicts
on the ChangeLog files.  Because of their very nature and purpose the
ChangeLog files get the most conflicts.  Normally very easy to resolve,
but still, a PITA.

Having the VC's built-in logging be the _only_ place your developers
write up their changes logs solves all of these issues.  And in my
experience, it does so painlessly.

We have never had a single problem, complaint or concern with using this
method of logging in SXEmacs, and I'd be only too happy to answer any
concerns that you or anyone else might have with moving to this
method.  Just Cc me or email me directly (I don't watch this list too
closely). 
(Continue reading)

Eli Zaretskii | 29 Mar 10:16 2013
Picon

Re: Abolishing ChangeLog files

> From: Steve Youngs <steve <at> sxemacs.org>
> Date: Fri, 29 Mar 2013 18:02:40 +1000
> Keywords: method,information,problem,place,logging
> 
> Your method does nothing to alleviate the problem of recurring conflicts
> on the ChangeLog files.

These conflicts only happen if changes are applied manually with
'patch' or similar.  When merging between branches, bzr handles
ChangeLog files specially, and avoids conflicts caused by addition of
entries.

John Wiegley | 29 Mar 15:20 2013

Re: Abolishing ChangeLog files

>>>>> Steve Youngs <steve <at> sxemacs.org> writes:

> Your method does nothing to alleviate the problem of recurring conflicts on
> the ChangeLog files.  Because of their very nature and purpose the ChangeLog
> files get the most conflicts.  Normally very easy to resolve, but still, a
> PITA.

Steve, Git does support "drivers" for its merge algorithm, for specialized
data types that might otherwise be prone to constant conflicts.  See:

    http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c

John

Steve Youngs | 30 Mar 00:06 2013
X-Face
Face

Re: Abolishing ChangeLog files

* John Wiegley <johnw <at> newartisans.com> writes:

  >>>>>> Steve Youngs <steve <at> sxemacs.org> writes:
  >> Your method does nothing to alleviate the problem of recurring conflicts on
  >> the ChangeLog files.  Because of their very nature and purpose the ChangeLog
  >> files get the most conflicts.  Normally very easy to resolve, but still, a
  >> PITA.

  > Steve, Git does support "drivers" for its merge algorithm, for specialized
  > data types that might otherwise be prone to constant conflicts.  See:

  >     http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c

Wow, there is just so much more to Git than meets the eye.  I had no
idea about this, thanks for showing me, John.

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|       SXEmacs - The only _______ you'll ever need.       |
|         Fill in the blank, yes, it's THAT good!          |
|------------------------------------<steve <at> sxemacs.org>---|

Richard Stallman | 29 Mar 19:37 2013
Picon
Picon

Re: Abolishing ChangeLog files

    Seems to me that it would be a lot more convenient if the "what" and the
    "why" of a change were in the same place.  That is where you are making
    the split, ChangeLogs for the what and commit logs for the why?

Yes.  It seems natural to me to have these separate, and also to
split up the ChangeLog files by directory.  It has two advantages:

(1) the explanation are easier to read when not cluttered by
all the details of what was changed.

(2) Each per-directory ChangeLog file is considerably shorter
than the whole collection.

(3) It is possible to fix errors in the ChangeLog files.
(Some VCS allow such changes -- RCS did.)

However, I don't insist about how Emacs does this.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Carsten Dominik | 28 Mar 12:05 2013
Picon

Re: Abolishing ChangeLog files (was: On the subject of Git, Bazaar, and the future of Emacs development)


On 28 mrt. 2013, at 10:55, Christopher Schmidt <christopher <at> ch.ristopher.com> wrote:

> David Engster <deng <at> randomsample.de> writes:
>> The most time consuming thing is fixing ChangeLogs (we don't have any
>> in CEDET and generate them from commit logs).
> 
> I would like to suggest another change - how about removing ChangeLog
> files from the development repository.  I think these files are
> redundant to the commit log of the vc.
> 
> Removing the files from the repository would clean diffs and reduce
> merge conflicts.  Considering distributed vc, a project's history cannot
> be thought of as to be list of consecutive increments.
> 
> Distributions of Emacs could include ChangeLog files generated from the
> vc commit log, of course.
> 
> Do I make sense?  Are there any drawbacks?

I think it makes sense.  In fact, org-mode does already create
ChangeLog entries automatically from git commit messages.  We
enforce commit message to have a section that does look just
like a ChangeLog entry, and we extract these when the time
is ripe for another merge with Emacs.  Here is a recent
example of such a commit message:

------------------------------------------------------------------------------------------
org.el (org-store-link): Storing multiple links in the active region now requires a triple prefix argument

(Continue reading)

Alan Mackenzie | 28 Mar 12:44 2013
Picon

Re: Abolishing ChangeLog files (was: On the subject of Git, Bazaar, and the future of Emacs development)

Hello, Christopher.

On Thu, Mar 28, 2013 at 09:55:29AM +0000, Christopher Schmidt wrote:
> David Engster <deng <at> randomsample.de> writes:
> > The most time consuming thing is fixing ChangeLogs (we don't have any
> > in CEDET and generate them from commit logs).

> I would like to suggest another change - how about removing ChangeLog
> files from the development repository.  I think these files are
> redundant to the commit log of the vc.

> Removing the files from the repository would clean diffs and reduce
> merge conflicts.  Considering distributed vc, a project's history cannot
> be thought of as to be list of consecutive increments.

> Distributions of Emacs could include ChangeLog files generated from the
> vc commit log, of course.

Of course?  Generating the (structured) ChangeLog from (free form) log
entrys isn't trivial.

> Do I make sense?  Are there any drawbacks?

Yes.  ChangeLog files are useful, e.g. for hunting down changes.  I do
this often enough that the lack of ChangeLogs would be inconvenient.  I
don't doubt that it's possible to wring the necessary info out of bzr,
I've done it, but it's not pleasant.

Anyway, whilst the choice of DVCS is up in the air is not the time to be
debating this question, IMAO.
(Continue reading)

David Engster | 28 Mar 12:56 2013
Picon

Re: Abolishing ChangeLog files

Alan Mackenzie writes:
> On Thu, Mar 28, 2013 at 09:55:29AM +0000, Christopher Schmidt wrote:
>> David Engster <deng <at> randomsample.de> writes:
>> > The most time consuming thing is fixing ChangeLogs (we don't have any
>> > in CEDET and generate them from commit logs).
>
>> I would like to suggest another change - how about removing ChangeLog
>> files from the development repository.  I think these files are
>> redundant to the commit log of the vc.
>
>> Removing the files from the repository would clean diffs and reduce
>> merge conflicts.  Considering distributed vc, a project's history cannot
>> be thought of as to be list of consecutive increments.
>
>> Distributions of Emacs could include ChangeLog files generated from the
>> vc commit log, of course.
>
> Of course?  Generating the (structured) ChangeLog from (free form) log
> entrys isn't trivial.

Indeed. That's why I wrote the time consuming thing is "fixing" those
generated ChangeLogs, like

- combining changes to the same file (and maybe function) which stretch
  over several commits,

- removing further explanations which are fine in commit logs but not in
  ChangeLogs,

- putting ChangeLogs entries in the right places (I have to deal with
(Continue reading)

Steve Youngs | 29 Mar 01:23 2013
X-Face
Face

Re: Abolishing ChangeLog files

* David Engster <deng <at> randomsample.de> writes:

  > Indeed. That's why I wrote the time consuming thing is "fixing" those
  > generated ChangeLogs, like

  > - combining changes to the same file (and maybe function) which stretch
  >   over several commits,

Having logs line up with commits is normally more of a benefit than an
annoyance IMO.

  > - removing further explanations which are fine in commit logs but not in
  >   ChangeLogs,

Don't be afraid of verbosity in logs. :-)  

  > - putting ChangeLogs entries in the right places (I have to deal with
  >   five different ChangeLogs: etc/, admin/, doc/misc, lisp/, and finally
  >   lisp/cedet),

Move to a single log model and then never have to worry about this step
again.

  > - and many more smaller things; sometimes commit logs just don't have
  >   the proper format.

I've not ever found a time when it didn't.

  > Much of this stuff could be automated, though.

(Continue reading)

Thierry Volpiatto | 28 Mar 12:59 2013
Picon

Re: Abolishing ChangeLog files

Alan Mackenzie <acm <at> muc.de> writes:

> Hello, Christopher.
>
> On Thu, Mar 28, 2013 at 09:55:29AM +0000, Christopher Schmidt wrote:
>> David Engster <deng <at> randomsample.de> writes:
>> > The most time consuming thing is fixing ChangeLogs (we don't have any
>> > in CEDET and generate them from commit logs).
>
>> I would like to suggest another change - how about removing ChangeLog
>> files from the development repository.  I think these files are
>> redundant to the commit log of the vc.
>
>> Removing the files from the repository would clean diffs and reduce
>> merge conflicts.  Considering distributed vc, a project's history cannot
>> be thought of as to be list of consecutive increments.
>
>> Distributions of Emacs could include ChangeLog files generated from the
>> vc commit log, of course.
>
> Of course?  Generating the (structured) ChangeLog from (free form) log
> entrys isn't trivial.
>
>> Do I make sense?  Are there any drawbacks?
>
> Yes.  ChangeLog files are useful, e.g. for hunting down changes.  I do
> this often enough that the lack of ChangeLogs would be inconvenient.  I
> don't doubt that it's possible to wring the necessary info out of bzr,
> I've done it, but it's not pleasant.

(Continue reading)

John Wiegley | 28 Mar 14:17 2013

Re: Abolishing ChangeLog files

>>>>> Alan Mackenzie <acm <at> muc.de> writes:

> Of course?  Generating the (structured) ChangeLog from (free form) log
> entrys isn't trivial.

Here is a script I use for creating GNU-style ChangeLog entries from the
output of 'git log':

    https://github.com/jwiegley/git-scripts/blob/master/git-changelog

John

Steve Youngs | 29 Mar 00:58 2013
X-Face
Face

Re: Abolishing ChangeLog files

* Alan Mackenzie <acm <at> muc.de> writes:

  > Generating the (structured) ChangeLog from (free form) log
  > entrys isn't trivial.

It isn't needed if you write structured log entries in the first place.
I think someone (Stefan?) already suggested... make
#'add-change-log-entry and friends DTRT.

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|       SXEmacs - The only _______ you'll ever need.       |
|         Fill in the blank, yes, it's THAT good!          |
|------------------------------------<steve <at> sxemacs.org>---|

Stefan Monnier | 28 Mar 13:41 2013
Picon

Re: Abolishing ChangeLog files

> I would like to suggest another change - how about removing ChangeLog
> files from the development repository.  I think these files are
> redundant to the commit log of the vc.

We already dropped them from `elpa', but my experience is that the support
for writing commit logs entries is not yet up-to-par with the support
for writing ChanegLog entries.  I encourage people to work on that
(e.g. make C-x 4 a do something useful for those projects that don't
use ChangeLog files).

> Of course?  Generating the (structured) ChangeLog from (free form) log
> entrys isn't trivial.

Luckily, that's not quite the problem we're trying to solve: the commit
log messages in Emacs should (and mostly do) follow the exact same
conventions as the ChangeLog entries.

> Because bzr log take ages to popup, I guess it is one reason you relay
> on changelog files.

Agreed.  Commit logs are much more useful in Git where they show up much
more quickly.

Another big issue is that commit logs can't be fixed (it's not an
inherent limitation, just a limitation of "bzr log" and AFAIK of "git
log" as well).

        Stefan

(Continue reading)

Eli Zaretskii | 28 Mar 17:34 2013
Picon

Re: Abolishing ChangeLog files

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Thu, 28 Mar 2013 08:41:25 -0400
> 
> > Because bzr log take ages to popup, I guess it is one reason you relay
> > on changelog files.
> 
> Agreed.  Commit logs are much more useful in Git where they show up much
> more quickly.

Not here:

  D:\gnu\bzr\emacs\trunk>timep bzr log --line -l5000 > nul

  real    00h00m00.921s
  user    00h00m00.875s
  sys     00h00m00.062s

  $ time git log --oneline -n5000 > /dev/null

  real    0m0.218s
  user    0m0.015s
  sys     0m0.015s

I hope you at least won't claim that 900 msec is "much more quickly"
than 200 msec.  (Not that anyone should ever need to look at 5000
revisions.)

Eli Zaretskii | 28 Mar 18:13 2013
Picon

Re: Abolishing ChangeLog files

> Date: Thu, 28 Mar 2013 18:34:41 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: emacs-devel <at> gnu.org
> 
>   D:\gnu\bzr\emacs\trunk>timep bzr log --line -l5000 > nul
> 
>   real    00h00m00.921s
>   user    00h00m00.875s
>   sys     00h00m00.062s
> 
>   $ time git log --oneline -n5000 > /dev/null
> 
>   real    0m0.218s
>   user    0m0.015s
>   sys     0m0.015s
> 
> I hope you at least won't claim that 900 msec is "much more quickly"
> than 200 msec.                                              ^^^^^^^

Err, I meant "slowly", of course.

Dmitry Gutov | 28 Mar 18:20 2013
Picon

Re: Abolishing ChangeLog files

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Date: Thu, 28 Mar 2013 08:41:25 -0400
>> 
>> > Because bzr log take ages to popup, I guess it is one reason you relay
>> > on changelog files.
>> 
>> Agreed.  Commit logs are much more useful in Git where they show up much
>> more quickly.
>
> Not here:
>
>   D:\gnu\bzr\emacs\trunk>timep bzr log --line -l5000 > nul
>
>   real    00h00m00.921s
>   user    00h00m00.875s
>   sys     00h00m00.062s
>
>   $ time git log --oneline -n5000 > /dev/null
>
>   real    0m0.218s
>   user    0m0.015s
>   sys     0m0.015s
>
> I hope you at least won't claim that 900 msec is "much more quickly"
> than 200 msec.  (Not that anyone should ever need to look at 5000
> revisions.)

Your conclusion here seems to be the reverse of what the command output
(Continue reading)

Eli Zaretskii | 28 Mar 18:34 2013
Picon

Re: Abolishing ChangeLog files

> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 28 Mar 2013 21:20:44 +0400
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, emacs-devel <at> gnu.org
> 
> >   D:\gnu\bzr\emacs\trunk>timep bzr log --line -l5000 > nul
> >
> >   real    00h00m00.921s
> >   user    00h00m00.875s
> >   sys     00h00m00.062s
> >
> >   $ time git log --oneline -n5000 > /dev/null
> >
> >   real    0m0.218s
> >   user    0m0.015s
> >   sys     0m0.015s
> >
> > I hope you at least won't claim that 900 msec is "much more quickly"
> > than 200 msec.  (Not that anyone should ever need to look at 5000
> > revisions.)
> 
> Your conclusion here seems to be the reverse of what the command output
> shows (900ms for Bazaar and 200ms for Git).

It was a typo.  See my followup message.

> In my experience, Bzr is especially slow when showing log for a subtree
> or a specific file.

I could ask you to show numbers (because I have no such experience),
but I won't.  No one in this thread wants any serious discussion,
(Continue reading)

Dmitry Gutov | 28 Mar 22:04 2013
Picon

Re: Abolishing ChangeLog files

On 28.03.2013 21:34, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Thu, 28 Mar 2013 21:20:44 +0400
>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, emacs-devel <at> gnu.org
>>
>>>    D:\gnu\bzr\emacs\trunk>timep bzr log --line -l5000 > nul
>>>
>>>    real    00h00m00.921s
>>>    user    00h00m00.875s
>>>    sys     00h00m00.062s
>>>
>>>    $ time git log --oneline -n5000 > /dev/null
>>>
>>>    real    0m0.218s
>>>    user    0m0.015s
>>>    sys     0m0.015s
>>>
>>> I hope you at least won't claim that 900 msec is "much more quickly"
>>> than 200 msec.  (Not that anyone should ever need to look at 5000
>>> revisions.)
>>
>> Your conclusion here seems to be the reverse of what the command output
>> shows (900ms for Bazaar and 200ms for Git).
>
> It was a typo.  See my followup message.

I saw it after I sent the reply.

To answer your question, then, yes, 4.5 times faster indeed is "much 
more quickly". The difference here is not critical, but nice to have.
(Continue reading)

Eli Zaretskii | 28 Mar 22:29 2013
Picon

Re: Abolishing ChangeLog files

> Date: Fri, 29 Mar 2013 01:04:35 +0400
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Cc: monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
> 
> To answer your question, then, yes, 4.5 times faster indeed is "much 
> more quickly". The difference here is not critical, but nice to have.

Get real!  This started from the example of someone looking at the log
entry; human needs much more than a few hundreds of milliseconds to
read it, so a difference of 700 msec (for 5000 revisions!) is entirely
irrelevant.  Do you really know someone who can read 5000 entries in
under one second?

> >> In my experience, Bzr is especially slow when showing log for a subtree
> >> or a specific file.
> >
> > I could ask you to show numbers (because I have no such experience),
> > but I won't.  No one in this thread wants any serious discussion,
> > anyway.
> 
> I would send you the numbers if you pointed me at the mingw port of 
> 'time' you're apparently using.

I wrote that program myself.  Unix 'time' cannot be ported, because it
uses too many Posix APIs.

> But here's an example command:
> 
>    git log lisp\progmodes\ruby-mode.el | less
> 
(Continue reading)

Dmitry Gutov | 28 Mar 23:42 2013
Picon

Re: Abolishing ChangeLog files

On 29.03.2013 1:29, Eli Zaretskii wrote:
>> Date: Fri, 29 Mar 2013 01:04:35 +0400
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Cc: monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
>>
>> To answer your question, then, yes, 4.5 times faster indeed is "much
>> more quickly". The difference here is not critical, but nice to have.
>
> Get real!  This started from the example of someone looking at the log
> entry; human needs much more than a few hundreds of milliseconds to
> read it, so a difference of 700 msec (for 5000 revisions!) is entirely
> irrelevant.  Do you really know someone who can read 5000 entries in
> under one second?

Why are you arguing with "nice to have"? I gave you a more significant 
example below.

>>>> In my experience, Bzr is especially slow when showing log for a subtree
>>>> or a specific file.
>>>
>>> I could ask you to show numbers (because I have no such experience),
>>> but I won't.  No one in this thread wants any serious discussion,
>>> anyway.
>>
>> I would send you the numbers if you pointed me at the mingw port of
>> 'time' you're apparently using.

> I wrote that program myself.  Unix 'time' cannot be ported, because it
> uses too many Posix APIs.

(Continue reading)

Eli Zaretskii | 29 Mar 06:45 2013
Picon

Re: Abolishing ChangeLog files

> Date: Fri, 29 Mar 2013 02:42:51 +0400
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
> 
> > I wrote that program myself.  Unix 'time' cannot be ported, because it
> > uses too many Posix APIs.
> 
> Since you don't seem inclined to distribute it, you won't get exact 
> numbers from me.

You never asked.  I can send the source to you privately, if you
want.

> For the record:
> 
> C:\Users\gutov\vc\emacs-git>git --version
> git version 1.8.0.msysgit.0

Same here:

  $ git version
  git version 1.8.0.msysgit.0

> >> Anyway, the most important speedup I expect to see is the time it takes
> >> to do "git pull" vs "bzr update". I haven't done any real testing there
> >> yet, but the latter command takes entirely too long.
> >
> > Depends on how large is your pull.  E.g., the initial "git clone" took
> > me almost 3 hours; bzr did the same in under 50 min.
> 
(Continue reading)

Eli Zaretskii | 29 Mar 07:10 2013
Picon

Re: Abolishing ChangeLog files

> Date: Fri, 29 Mar 2013 08:45:44 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
> 
> > Date: Fri, 29 Mar 2013 02:42:51 +0400
> > From: Dmitry Gutov <dgutov <at> yandex.ru>
> > CC: monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
> > 
> > > I wrote that program myself.  Unix 'time' cannot be ported, because it
> > > uses too many Posix APIs.
> > 
> > Since you don't seem inclined to distribute it, you won't get exact 
> > numbers from me.
> 
> You never asked.  I can send the source to you privately, if you
> want.

Btw: bzr logs all of its times in .bzr.log, so you don't need any
additional programs to time it.  (I wish git had such a comprehensive
logging facility, it proved invaluable for me quite a few times in the
past.)

Thierry Volpiatto | 29 Mar 07:43 2013
Picon

Re: Abolishing ChangeLog files

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Fri, 29 Mar 2013 08:45:44 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
>> 
>> > Date: Fri, 29 Mar 2013 02:42:51 +0400
>> > From: Dmitry Gutov <dgutov <at> yandex.ru>
>> > CC: monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
>> > 
>> > > I wrote that program myself.  Unix 'time' cannot be ported, because it
>> > > uses too many Posix APIs.
>> > 
>> > Since you don't seem inclined to distribute it, you won't get exact 
>> > numbers from me.
>> 
>> You never asked.  I can send the source to you privately, if you
>> want.
>
> Btw: bzr logs all of its times in .bzr.log, so you don't need any
> additional programs to time it.  (I wish git had such a comprehensive
> logging facility, it proved invaluable for me quite a few times in the
> past.)

From the bzr documentation:
http://doc.bazaar.canonical.com/beta/en/user-reference/log-help.html

,----
| bzr log -v on a branch with lots of history is currently very slow. A
| fix for this issue is currently under development. With or without that
(Continue reading)

Eli Zaretskii | 29 Mar 08:08 2013
Picon

Re: Abolishing ChangeLog files

> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Date: Fri, 29 Mar 2013 07:43:03 +0100
> 
> > Btw: bzr logs all of its times in .bzr.log, so you don't need any
> > additional programs to time it.  (I wish git had such a comprehensive
> > logging facility, it proved invaluable for me quite a few times in the
> > past.)
> 
> >From the bzr documentation:
> http://doc.bazaar.canonical.com/beta/en/user-reference/log-help.html
> 
> ,----
> | bzr log -v on a branch with lots of history is currently very slow. A
> | fix for this issue is currently under development. With or without that
> | fix, it is recommended that a revision range be given when using the -v
> | option.
> `----
> 
> Each time I tried bzr log (when I had bzr) it ends up With C-c because
> it was too long (against the emacs trunk), so I always had a copy of
> emacs converted to hg or git to be able to see the full logs.
> So no need to use time to measure the slowness (at least for me).

I showed you the times, which I think don't come anywhere near "very
slow".  If you are willing to believe to some piece of documentation
rather than measurements, then I must say your conclusions have no
real basis in reality.

Stephen J. Turnbull | 29 Mar 09:38 2013
Picon

Re: Abolishing ChangeLog files

Eli Zaretskii writes:
 > > From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>

 > > Each time I tried bzr log (when I had bzr) it ends up With C-c because
 > > it was too long (against the emacs trunk), so I always had a copy of
 > > emacs converted to hg or git to be able to see the full logs.
 > > So no need to use time to measure the slowness (at least for me).
 > 
 > I showed you the times, which I think don't come anywhere near "very
 > slow".  If you are willing to believe to some piece of documentation
 > rather than measurements, then I must say your conclusions have no
 > real basis in reality.

Eli, he probably *was* measuring, although not as precisely as you
are since his stopwatch was implemented in impatience units rather
than seconds.

One potential point of confusion is that bzr does a good job of
concealing the fact that the repo may be on the other side of the
world, whereas in git the repo is always local (even with a shallow
clone).  If he was trying to get logs in a checkout, that would
explain why he "always" had to C-c.

Thierry, is that a possible explanation for your experience?

Eli Zaretskii | 29 Mar 10:18 2013
Picon

Re: Abolishing ChangeLog files

> From: "Stephen J. Turnbull" <stephen <at> xemacs.org>
> Cc: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>,
>     emacs-devel <at> gnu.org
> Date: Fri, 29 Mar 2013 17:38:10 +0900
> 
> Eli Zaretskii writes:
>  > > From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> 
>  > > Each time I tried bzr log (when I had bzr) it ends up With C-c because
>  > > it was too long (against the emacs trunk), so I always had a copy of
>  > > emacs converted to hg or git to be able to see the full logs.
>  > > So no need to use time to measure the slowness (at least for me).
>  > 
>  > I showed you the times, which I think don't come anywhere near "very
>  > slow".  If you are willing to believe to some piece of documentation
>  > rather than measurements, then I must say your conclusions have no
>  > real basis in reality.
> 
> Eli, he probably *was* measuring, although not as precisely as you
> are since his stopwatch was implemented in impatience units rather
> than seconds.

Possibly.  But I would expect numbers, even approximate (counting
seconds is easy), instead of references to docs.

Stephen J. Turnbull | 29 Mar 11:11 2013
Picon

Re: Abolishing ChangeLog files

Eli Zaretskii writes:

 > Possibly.  But I would expect numbers, even approximate (counting
 > seconds is easy), instead of references to docs.

It's hard to count seconds that would have passed if you didn't C-c
out. ;-)  And since YMMV, the reference to docs shows that the Bazaar
developers have acknowledged performance issues, even if not all users
experience them.

Eli Zaretskii | 29 Mar 11:50 2013
Picon

Re: Abolishing ChangeLog files

> From: "Stephen J. Turnbull" <stephen <at> xemacs.org>
> Cc: emacs-devel <at> gnu.org,
>     thierry.volpiatto <at> gmail.com
> Date: Fri, 29 Mar 2013 19:11:24 +0900
> 
> Eli Zaretskii writes:
> 
>  > Possibly.  But I would expect numbers, even approximate (counting
>  > seconds is easy), instead of references to docs.
> 
> It's hard to count seconds that would have passed if you didn't C-c
> out. ;-)

Well, I wouldn't expect anyone to type C-c less than 4 sec after
launching a command.  But if a lightweight checkout is being used, I
can understand all the rest, including the long times.  That is not
the recommended workflow, though.

> And since YMMV, the reference to docs shows that the Bazaar
> developers have acknowledged performance issues, even if not all
> users experience them.

I'd rather assume the docs are outdated.  Won't be the first time with
bzr.

Thierry Volpiatto | 29 Mar 12:11 2013
Picon

Re: Abolishing ChangeLog files

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: "Stephen J. Turnbull" <stephen <at> xemacs.org>
>> Cc: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>,
>>     emacs-devel <at> gnu.org
>> Date: Fri, 29 Mar 2013 17:38:10 +0900
>> 
>> Eli Zaretskii writes:
>>  > > From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> 
>>  > > Each time I tried bzr log (when I had bzr) it ends up With C-c because
>>  > > it was too long (against the emacs trunk), so I always had a copy of
>>  > > emacs converted to hg or git to be able to see the full logs.
>>  > > So no need to use time to measure the slowness (at least for me).
>>  > 
>>  > I showed you the times, which I think don't come anywhere near "very
>>  > slow".  If you are willing to believe to some piece of documentation
>>  > rather than measurements, then I must say your conclusions have no
>>  > real basis in reality.
>> 
>> Eli, he probably *was* measuring, although not as precisely as you
>> are since his stopwatch was implemented in impatience units rather
>> than seconds.
>
> Possibly.  But I would expect numbers, even approximate (counting
> seconds is easy), instead of references to docs.

Eli, I will not send you numbers because I don't use anymore bzr, and
even if I reinstall it (this is easy) I will have to get emacs with bzr
branch which is a nightmare, it will take a full day with all errors,
(Continue reading)

Eli Zaretskii | 29 Mar 12:43 2013
Picon

Re: Abolishing ChangeLog files

> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Cc: "Stephen J. Turnbull" <stephen <at> xemacs.org>,  emacs-devel <at> gnu.org
> Date: Fri, 29 Mar 2013 12:11:45 +0100
> 
> Eli, I will not send you numbers because I don't use anymore bzr, and
> even if I reinstall it (this is easy) I will have to get emacs with bzr
> branch which is a nightmare, it will take a full day with all errors,
> crash, workaround to find, etc..., so no sorry.

Fine with me, but in that case, would you please refrain from posting
unsubstantiated claims about bzr speed that no one can confirm or
refute?

Thierry Volpiatto | 29 Mar 12:00 2013
Picon

Re: Abolishing ChangeLog files

"Stephen J. Turnbull" <stephen <at> xemacs.org> writes:

> Eli Zaretskii writes:
>  > > From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>
>  > > Each time I tried bzr log (when I had bzr) it ends up With C-c because
>  > > it was too long (against the emacs trunk), so I always had a copy of
>  > > emacs converted to hg or git to be able to see the full logs.
>  > > So no need to use time to measure the slowness (at least for me).
>  > 
>  > I showed you the times, which I think don't come anywhere near "very
>  > slow".  If you are willing to believe to some piece of documentation
>  > rather than measurements, then I must say your conclusions have no
>  > real basis in reality.
>
> Eli, he probably *was* measuring, although not as precisely as you
> are since his stopwatch was implemented in impatience units rather
> than seconds.
>
> One potential point of confusion is that bzr does a good job of
> concealing the fact that the repo may be on the other side of the
> world, whereas in git the repo is always local (even with a shallow
> clone).  If he was trying to get logs in a checkout, that would
> explain why he "always" had to C-c.
>
> Thierry, is that a possible explanation for your experience?
Well, I did bzr log on the local directory where I bzr branch'ed from
savannah.
Do you mean that when I did that bzr log was running remote to get log ?!

(Continue reading)

Eli Zaretskii | 29 Mar 12:41 2013
Picon

Re: Abolishing ChangeLog files

> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  emacs-devel <at> gnu.org
> Date: Fri, 29 Mar 2013 12:00:13 +0100
> 
> Well, I did bzr log on the local directory where I bzr branch'ed from
> savannah.
> Do you mean that when I did that bzr log was running remote to get log ?!

Only if your bzr Emacs directory was a "lightweight checkout", i.e. it
lacked local copy of the history meta-data.  But if you created it
with "bzr branch", then no, "bzr log" should never go to the remote
server, but instead use the local data.

Stephen J. Turnbull | 29 Mar 23:15 2013
Picon

Re: Abolishing ChangeLog files

Thierry Volpiatto writes:

 > > Thierry, is that a possible explanation for your experience?

 > Well, I did bzr log on the local directory where I bzr branch'ed from
 > savannah.

If you used "bzr branch" and did not convert the branch to a checkout,
then that is not what I'm talking about.  To get the effect of going
to remote for almost everything, you would most likely use "bzr
checkout --lightweight".

 > Do you mean that when I did that bzr log was running remote to get log ?!

It's possible, but if you did "bzr branch" to fetch the sources
originally, I don't think that's the explanation.

Dmitry Gutov | 29 Mar 16:07 2013
Picon

Re: Abolishing ChangeLog files

On 29.03.2013 10:10, Eli Zaretskii wrote:
>> Date: Fri, 29 Mar 2013 08:45:44 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
> Btw: bzr logs all of its times in .bzr.log, so you don't need any
> additional programs to time it.  (I wish git had such a comprehensive
> logging facility, it proved invaluable for me quite a few times in the
> past.)
>

If you mean that it writes to ~/bazaar/.bzr.log, then it doesn't, here. 
The file exists, but all the entries there are from September 1st last 
year. Not important, just an aside.

 > Attached below.

Thank you. It inspired me to run the same non-interactive tests you did, 
and indeed the full 'git log lisp\progmodes\ruby-mode.el > NUL' 
invocation is non-instantaneous every time, and it's on the same order 
of magnitude as 'bzr log', although the latter takes twice as long:

emacs-git-savannah>timep git log lisp\progmodes\ruby-mode.el > NUL

real    00h00m04.652s
user    00h00m00.000s
sys     00h00m00.015s

emacs-bzr\trunk>timep bzr log lisp\progmodes\ruby-mode.el > NUL

real    00h00m08.269s
(Continue reading)

Eli Zaretskii | 29 Mar 16:36 2013
Picon

Re: Abolishing ChangeLog files

> Date: Fri, 29 Mar 2013 19:07:50 +0400
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: emacs-devel <at> gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> 
> On 29.03.2013 10:10, Eli Zaretskii wrote:
> >> Date: Fri, 29 Mar 2013 08:45:44 +0300
> >> From: Eli Zaretskii <eliz <at> gnu.org>
> >> Cc: monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
> > Btw: bzr logs all of its times in .bzr.log, so you don't need any
> > additional programs to time it.  (I wish git had such a comprehensive
> > logging facility, it proved invaluable for me quite a few times in the
> > past.)
> >
> 
> If you mean that it writes to ~/bazaar/.bzr.log, then it doesn't, here. 
> The file exists, but all the entries there are from September 1st last 
> year. Not important, just an aside.

It's ~/.bzr.log, not ~/bazaar/.bzr.log.

> Thank you. It inspired me to run the same non-interactive tests you did, 
> and indeed the full 'git log lisp\progmodes\ruby-mode.el > NUL' 
> invocation is non-instantaneous every time, and it's on the same order 
> of magnitude as 'bzr log', although the latter takes twice as long:
> 
> emacs-git-savannah>timep git log lisp\progmodes\ruby-mode.el > NUL
> 
> real    00h00m04.652s
> user    00h00m00.000s
> sys     00h00m00.015s
(Continue reading)

Dmitry Gutov | 29 Mar 16:58 2013
Picon

Re: Abolishing ChangeLog files

On 29.03.2013 19:36, Eli Zaretskii wrote:
> It's ~/.bzr.log, not ~/bazaar/.bzr.log.
>

Ah, it works fine, then. Thanks.

>> Thank you. It inspired me to run the same non-interactive tests you did,
>> and indeed the full 'git log lisp\progmodes\ruby-mode.el > NUL'
>> invocation is non-instantaneous every time, and it's on the same order
>> of magnitude as 'bzr log', although the latter takes twice as long:
>>
>> emacs-git-savannah>timep git log lisp\progmodes\ruby-mode.el > NUL
>>
>> real    00h00m04.652s
>> user    00h00m00.000s
>> sys     00h00m00.015s
>>
>> emacs-bzr\trunk>timep bzr log lisp\progmodes\ruby-mode.el > NUL
>>
>> real    00h00m08.269s
>> user    00h00m07.878s
>> sys     00h00m00.280s
>>
>> But! Git starts streaming output just as soon as it can, hence my
>> earlier impression that the command is instantaneous.
>
> That only matters if you want the first few revisions.  What if you
> want the last?

The most recent revisions are streamed first (they're at the top), and 
(Continue reading)

Eli Zaretskii | 29 Mar 18:16 2013
Picon

Re: Abolishing ChangeLog files

> Date: Fri, 29 Mar 2013 19:58:58 +0400
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: emacs-devel <at> gnu.org, monnier <at> IRO.UMontreal.CA
> 
> >> I don't have a similar result for Git
> >> to compare, but considering it cloned the whole history in 30 minutes
> >> (same as on your machine)
> >
> > You are mistaken, a full clone took me 3 hours, not 30 min.
> 
> I misremembered, then. But it definitely took me 30 minutes today to 
> make a new clone of git://git.savannah.gnu.org/emacs.
> 
> I guess that means that my network is fine. You, on the other hand, may 
> be hitting a bottleneck there. This could explain why network operations 
> of Git and Bazaar take the same time on your machine.

No, it can't.  My network connection gives me 30Mbps, and I get 20Mbps
downloading from a server in Washington, DC.

chad | 29 Mar 21:58 2013
Picon

Re: Abolishing ChangeLog files


On 29 Mar 2013, at 08:58, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
I misremembered, then. But it definitely took me 30 minutes today to make a new clone of git://git.savannah.gnu.org/emacs.

FWIW, I just did this for the first time, on a reasonably modern macosx laptop and residential cable modem inside the US:

Cloning into 'emacs'...
remote: Counting objects: 702132, done.
remote: Compressing objects: 100% (140829/140829), done.
remote: Total 702132 (delta 562334), reused 699521 (delta 560328)
Receiving objects: 100% (702132/702132), 863.79 MiB | 297 KiB/s, done.
Resolving deltas: 100% (562334/562334), done.
135.588u 14.156s 16:43.53 14.9% 0+0k 327+2868io 3pf+0w

In case it's not clear, the wall-clock time was 16 minutes, 43.53 seconds.

~Chad
Dmitry Gutov | 29 Mar 07:43 2013
Picon

Re: Abolishing ChangeLog files

On 29.03.2013 9:45, Eli Zaretskii wrote:
>> Date: Fri, 29 Mar 2013 02:42:51 +0400
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> CC: monnier <at> iro.umontreal.ca, emacs-devel <at> gnu.org
>>
>>> I wrote that program myself.  Unix 'time' cannot be ported, because it
>>> uses too many Posix APIs.
>>
>> Since you don't seem inclined to distribute it, you won't get exact
>> numbers from me.
>
> You never asked.  I can send the source to you privately, if you
> want.

Please do. Hopefully, it's not hard to compile.

Stefan Monnier | 28 Mar 21:58 2013
Picon

Re: Abolishing ChangeLog files

>> Agreed.  Commit logs are much more useful in Git where they show up much
>> more quickly.
> Not here:

Obviously, it depends on the specific case.  My use cases are mostly
"C-x v l" from a file, with default settings.  Also I have not measured
it, so maybe it simply appears faster (e.g. because it starts giving
output sooner).

        Stefan

Nikolai Weibull | 29 Mar 22:53 2013
Picon

Re: Abolishing ChangeLog files

On Thu, Mar 28, 2013 at 1:41 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:

> Another big issue is that commit logs can't be fixed (it's not an
> inherent limitation, just a limitation of "bzr log" and AFAIK of "git
> log" as well).

There’s “git notes”.

Also, fixing the last (unpushed) commit message is easy to do with
“git commit --amend” and fixing unpushed commits can be done with “git
rebase”.

Stefan Monnier | 30 Mar 03:20 2013
Picon

Re: Abolishing ChangeLog files

> “git commit --amend” and fixing unpushed commits can be done with “git
> rebase”.

Neither of which can be used on a branch such as Emacs's trunk without
screwing over everybody who already pulled from the previous version.

        Stefan

Nikolai Weibull | 30 Mar 09:07 2013
Picon

Re: Abolishing ChangeLog files

On Sat, Mar 30, 2013 at 3:20 AM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> “git commit --amend” and fixing unpushed commits can be done with “git
>> rebase”.

> Neither of which can be used on a branch such as Emacs's trunk without
> screwing over everybody who already pulled from the previous version.

Yes, that’s why I qualified it with “unpushed”.

Stefan Monnier | 28 Mar 13:35 2013
Picon

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

>        /--to-emacs  <-|   --------------------->
>       /        ^      |         diff|patch
>      |         |      |
>      |         |      |
> CEDET ----trunk|    <-|                         Emacs trunk
>      |                |
>      |                |
>       \               |         diff|patch
>        \--from-emacs -|   <--------------------
[...]
> Emacs->CEDET: Now that's tedious. You have to first generate a list of
> commits in Emacs trunk which changed files from CEDET.

Hmm... Why don't you have a more symmetric setup.  I.e. have
a "to-cedet" branch on the Emacs side, where the non-CEDET files are
removed and the CEDET files are renamed appropriately?

        Stefan

David Engster | 28 Mar 14:08 2013
Picon

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

Stefan Monnier writes:
>>        /--to-emacs  <-|   --------------------->
>>       /        ^      |         diff|patch
>>      |         |      |
>>      |         |      |
>> CEDET ----trunk|    <-|                         Emacs trunk
>>      |                |
>>      |                |
>>       \               |         diff|patch
>>        \--from-emacs -|   <--------------------
> [...]
>> Emacs->CEDET: Now that's tedious. You have to first generate a list of
>> commits in Emacs trunk which changed files from CEDET.
>
> Hmm... Why don't you have a more symmetric setup.  I.e. have
> a "to-cedet" branch on the Emacs side, where the non-CEDET files are
> removed and the CEDET files are renamed appropriately?

I have thought of doing a similar setup on the Emacs side. The main
problem is that I'd have a huge list of conflicts every time I merge
from trunk (for every file that was changed which is not in
'to-cedet'). I could probably script things to resolve those
automatically, though.  Still, getting the list of commits which change
CEDET files is not difficult, aside from taking several minutes to
complete (basically bzr log lisp/cedet lisp/emacs-lisp/eieio* ...).

The real work is getting the patches to apply upstream, resolve
conflicts and not loose track of what you've already merged (although I
guess I should just merge more often...).

-David

Stephen J. Turnbull | 29 Mar 08:00 2013
Picon

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

David Engster writes:

 > Emacs->CEDET: Now that's tedious. You have to first generate a list of
 > commits in Emacs trunk which changed files from CEDET. Then you try to
 > cherry-pick those commits into the 'from-emacs' branch.

Have you tried Robert Collins' looms?  It seems to me that they would
help with this (but last time I checked they require a different
branch format).

David Engster | 29 Mar 11:14 2013
Picon

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

Stephen J. Turnbull writes:
> David Engster writes:
>
>  > Emacs->CEDET: Now that's tedious. You have to first generate a list of
>  > commits in Emacs trunk which changed files from CEDET. Then you try to
>  > cherry-pick those commits into the 'from-emacs' branch.
>
> Have you tried Robert Collins' looms?  It seems to me that they would
> help with this (but last time I checked they require a different
> branch format).

It looks interesting, but I haven't tried it, because as you say, it
converts your branches so that you can only use them with the loom
plugin afterwards. Also, development on the loom plugin seems to have
stalled, to no surprise of anyone.

I'm already worried enough that the CEDET repository seems to be locked
inside bzr with no available conversion, so I'm not eager to further
complicate things.  I'm really hoping that with Richard weighing in,
things will improve again.  I think our time is better spend then
switching yet again to another VCS.

-David

joakim | 29 Mar 22:27 2013
Picon

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

David Engster <deng <at> randomsample.de> writes:

> Stephen J. Turnbull writes:
>> David Engster writes:
>>
>>  > Emacs->CEDET: Now that's tedious. You have to first generate a list of
>>  > commits in Emacs trunk which changed files from CEDET. Then you try to
>>  > cherry-pick those commits into the 'from-emacs' branch.
>>
>> Have you tried Robert Collins' looms?  It seems to me that they would
>> help with this (but last time I checked they require a different
>> branch format).
>
> It looks interesting, but I haven't tried it, because as you say, it
> converts your branches so that you can only use them with the loom
> plugin afterwards. Also, development on the loom plugin seems to have
> stalled, to no surprise of anyone.

I tried looms for a while. While fine on paper, there were many
practical issues, so I stopped. Just a datapoint.

> I'm already worried enough that the CEDET repository seems to be locked
> inside bzr with no available conversion, so I'm not eager to further
> complicate things.  I'm really hoping that with Richard weighing in,
> things will improve again.  I think our time is better spend then
> switching yet again to another VCS.
>
> -David
>

--

-- 
Joakim Verona

Stefan Monnier | 28 Mar 03:43 2013
Picon

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

>> The core of the problem is bidirectional merging.  
> If I understand what you mean by "bidirectional merging", then monotone
> handles it nicely (http://www.monotone.ca/).

By bidirectional merging, I mean that you have two parallel branches
that should be kept in sync, so that any commit on branch A should be
sync'd to branch B and vice versa.  Yet branch A and branch B are not
identical (there's a "constant" diff between the two).

        Stefan

Kolo Rahl | 28 Mar 04:22 2013
Picon

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

Question about these "bidirectional" merge situations: how often do they happen and what is an example of one? I'm honestly curious, as it seems that such a development flow would imply a cyclic set of dependencies between the two branches. A _needs_ to be in sync with B only if it has a dependency on work in the B branch and vice versa, so if A and B branches both need to be constantly sync'd with each other, that means they have cyclic dependencies, right?


On Wed, Mar 27, 2013 at 7:43 PM, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>> The core of the problem is bidirectional merging.
> If I understand what you mean by "bidirectional merging", then monotone
> handles it nicely (http://www.monotone.ca/).

By bidirectional merging, I mean that you have two parallel branches
that should be kept in sync, so that any commit on branch A should be
sync'd to branch B and vice versa.  Yet branch A and branch B are not
identical (there's a "constant" diff between the two).


        Stefan


Stefan Monnier | 28 Mar 13:27 2013
Picon

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

> Question about these "bidirectional" merge situations: how often do they
> happen and what is an example of one?

Sync'ing Emacs and CEDET, or Emacs and Gnus, or ...

        Stefan

Stephen Leake | 28 Mar 09:08 2013
Picon

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

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> The core of the problem is bidirectional merging.  
>> If I understand what you mean by "bidirectional merging", then monotone
>> handles it nicely (http://www.monotone.ca/).
>
> By bidirectional merging, I mean that you have two parallel branches
> that should be kept in sync, so that any commit on branch A should be
> sync'd to branch B and vice versa.  Yet branch A and branch B are not
> identical (there's a "constant" diff between the two).

Ah. That is not what I thought.

A use case for this would be support for old Emacs versions in the
upstream of an Emacs feature, but only the current Emacs in the Emacs
trunk.

monotone does not handle that directly; it would be an interesting
feature to add. But it would make more sense to add it to git.

--

-- 
-- Stephe


Gmane