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

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

[John Wiegley]

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

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

[Jordi Gutiérrez Hermoso]

On 26 March 2013 15:38, John Wiegley <johnw@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.

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

[Stefan Monnier]

> 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

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

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Timur Aydin]

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

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

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

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

[Eli Zaretskii]

> From: Teemu Likonen <tlikonen@iki.fi>
> Date: Tue, 02 Apr 2013 16:30:34 +0300
> Cc: emacs-devel@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.

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

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

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

> From: Teemu Likonen <tlikonen@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

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

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

[Eli Zaretskii]

> From: Teemu Likonen <tlikonen@iki.fi>
> Cc: ta@taydin.org, emacs-devel@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@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
>     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

I don't think Velmer was talking about git.

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

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

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

> From: Teemu Likonen <tlikonen@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.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

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

[Eli Zaretskii]

> Date: Tue, 02 Apr 2013 11:56:25 +0300
> From: Timur Aydin <ta@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"?

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

[Xue Fuqiao]

On Mon, 1 Apr 2013 20:31:40 -0400
Barry Warsaw <barry@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/

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

[Alan Mackenzie]

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

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

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

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

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

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

[Eli Zaretskii]

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

He, Texinfo just switched from CVS to svn.

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

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Tue, 2 Apr 2013 11:45:08 -0400
>> From: Barry Warsaw <barry@python.org>
>> Cc: Alan Mackenzie <acm@muc.de>, emacs-devel@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

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

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

[Christopher Schmidt]

Alan Mackenzie <acm@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

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

[Alan Mackenzie]

On Tue, Apr 02, 2013 at 04:16:19PM +0100, Christopher Schmidt wrote:
> Alan Mackenzie <acm@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

>     http://git-scm.com/book

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

I'll give it a look, sometime.

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

Good!

>         Christopher

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Karl Fogel]

"John Wiegley" <johnw@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
home page at http://bazaar.canonical.com/en/.

There is a small amount of activity in the bug tracker, but IMHO not
enough.  For example, look at the "89 New Bugs" [1] and make sure to use
the little gear icon to turn on "Date Last Updated" and "Age" columns;
click either column to sort by that column.  What you'll see is that
after the first 7 bugs, the next most recently filed new bug was filed
more than four months ago.  Of the first 7, only a few have meaningful
responses (whether from a maintainer or otherwise).

The needle on the "project health meter" in my head is hovering down
near the low end of the dial.

As a minor package maintainer in Emacs, I would be better able to do my
job if the master Emacs sources were in Git.  I don't use Bazaar for
anything else now, so it's just another slightly different command set
to remember.  And it's clearly causing us trouble interacting with
packages whose upstream maintenance happens outside our tree, in git.

And for what?  So we can say we're supporting a "GNU Project"?  What a
fascinating vector for a DoS attack: call $FOO a GNU Project and get
Emacs to use it.  Then don't maintain $FOO.

I like Bazaar, and personally like the people who work on it (many of
whom I've been lucky enough to meet).  Canonical took a big risk
developing it, and Bzr may well still be the right tool for the import
of upstream sources into Launchpad for Ubuntu packaging.  But for an
independent upstream like Emacs, git long ago became the right choice.
Maybe Emacs' decision to use Bazaar in order to support a fellow GNU
project was the right at one time... but surely that decision's
rightness can & should change based on changes in the status of Bzr and
Emacs' needs?

-Karl

[1] https://bugs.launchpad.net/bzr/+bugs?search=Search&field.status=New&orderby=-date_last_updated&start=0

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

[Juanma Barranquero]

On Tue, Mar 26, 2013 at 9:55 PM, Karl Fogel <kfogel@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

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

[Richard Stallman]

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

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

[Thierry Volpiatto]

Richard Stallman <rms@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 

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

[Dmitry Gutov]

Richard Stallman <rms@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.

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

[Stephen J. Turnbull]

Dmitry Gutov writes:
 > Richard Stallman <rms@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.

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

[Allen S. Rout]

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

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

[Dmitry Gutov]

"Allen S. Rout" <asr@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).

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

[Stephen J. Turnbull]

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.

The fact is that Bazaar is much better now than it was then.  It's
quite usable in a project the size of Emacs these days.[1]  That's why
I say you're not going to change Richard's mind without much stronger
reasons than any I know of at this date.

Footnotes: 
[1]  Assuming you haven't already decided that you need git. ;-)

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

[Richard Stallman]

    > 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

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

[Juanma Barranquero]

On Wed, Mar 27, 2013 at 6:15 PM, Richard Stallman <rms@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

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

[John Yates]

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@gmail.com> wrote:
> On Wed, Mar 27, 2013 at 6:15 PM, Richard Stallman <rms@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
>

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

[Werner LEMBERG]

> 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

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

[Richard Stallman]

    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

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

[Leo Liu]

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

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

[joakim]

Richard Stallman <rms@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
  for these, some of them provided by Emacs developers. They never enter
  upstream. By "never" I mean years. This is bad.

The situation generates a lot of frustration.

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

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

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


-- 
Joakim Verona

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

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

() joakim@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

Please, let's continue this on the guile-user list.

-- 
Thien-Thi Nguyen
GPG key: 4C807502

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Richard Stallman]

    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

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

[Karl Fogel]

Richard Stallman <rms@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
on the grounds that you no longer have time to do a good job of this
evaluation?  You delegate other things.  Why is this special?

You wrote:

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

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

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

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

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

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

-Karl

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

[Richard Stallman]

    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

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

[Juanma Barranquero]

On Fri, Mar 29, 2013 at 4:48 AM, Richard Stallman <rms@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

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

[Karl Fogel]

Richard Stallman <rms@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
bug tracker and getting a sense of its overall maintenance state.  If
you do that, I will believe the conclusion you come to.  But you've
indicated you will not do that.  (I have done it, and came tentatively
to a conclusion; it could be refuted by real research from you, but not
by you getting a single answer from a single person about a single bug.)

-Karl

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

[Richard Stallman]

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

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

[Richard Stallman]

    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

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

[Juanma Barranquero]

On Thu, Mar 28, 2013 at 5:20 AM, Richard Stallman <rms@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

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

[Stefan Monnier]

> 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

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

[Richard Stallman]

    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
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

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

[John Wiegley]

>>>>> Richard Stallman <rms@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

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

[Eli Zaretskii]

> From: "John Wiegley" <johnw@newartisans.com>
> Date: Thu, 28 Mar 2013 19:26:58 +0000
> Cc: emacs-devel@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

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

[Richard Stallman]

    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

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

[Eli Zaretskii]

> Date: Thu, 28 Mar 2013 14:58:52 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@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

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

[Allen S. Rout]

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

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

[Josh]

On Wed, Mar 27, 2013 at 11:48 AM, Allen S. Rout <asr@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
> unambiguous is IMO a waste of time.  A 5 year sample (the conversation
> from March 2008) to now seems sufficient rope.

+1

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

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen J. Turnbull]

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.

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

[chad]

On 01 Apr 2013, at 20:24, Stephen J. Turnbull <stephen@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
attractive.

I hope this helps.
~Chad

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

[Eli Zaretskii]

> From: chad <yandros@MIT.EDU>
> Date: Tue, 2 Apr 2013 01:25:41 -0700
> Cc: Barry Warsaw <barry@python.org>, "Stephen J. Turnbull" <stephen@xemacs.org>
> 
> On 01 Apr 2013, at 20:24, Stephen J. Turnbull <stephen@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
least 5 years.

If I were reasoning like you do, I'd never have written the
bidirectional display code.  Why did I?  Because (1) it was a feature
I lacked in Emacs and knew I would use when it's available, and (2) it
pissed me off to have to use those "other tools" whenever I needed
this feature.  IOW, I was motivated, and also experienced enough in
the programming paradigms required to do the job, however hard (it
eventually took me 2 full years).

Doesn't this remind you something?

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

[chad]

On 02 Apr 2013, at 09:35, Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: chad <yandros@MIT.EDU>
> Date: Tue, 2 Apr 2013 10:57:03 -0700
> Cc: "emacs-devel@gnu.org Development" <emacs-devel@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.

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

[chad]

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

>> From: chad <yandros@MIT.EDU>
>> Date: Tue, 2 Apr 2013 10:57:03 -0700
>> Cc: "emacs-devel@gnu.org Development" <emacs-devel@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

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

[Jose E. Marchesi]

    >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

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

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Jay Belanger]

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

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

[Karl Fogel]

Jay Belanger <jay.p.belanger@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

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

[Richard Stallman]

      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
standards for command-line options.  It is important to make all GNU
programs follow these standards, where they are applicable.

Another important GNU standard is that GNU programs should come with
documentation in Texinfo format.  That is the GNU standard
documentation format, and it can be converted automatically into
various other formats.  You can use DocBook format or another suitable
format for the documentation sources, as long as converting it
automatically into Texinfo gives good results.

If a GNU program wants to be extensible, it should use GUILE
(http://www.gnu.org/software/guile/guile.html) as the programming
language for extensibility--that is the GNU standard extensibility
package.  For some programs there's a reason to do things differently,
but please use GUILE if that is feasible.

A GNU program should use the latest version of the license that the
GNU Project recommends--not just any free software license.  For most
packages, this means using the GNU GPL.

A GNU program should not recommend use of any non-free program, and it
should not refer the user to any non-free documentation for free
software.  The campaign for free documentation to go with free
software is a major focus of the GNU project (see
http://www.gnu.org/philosophy/free-doc.html); to show that we are
serious about it, we must not undermine our position by recommending
documentation that isn't free.

Occasionally there are issues of terminology which are important for
the success of the GNU project as a whole.  So we expect maintainers
of GNU programs to follow them.  For example, the documentation files
and comments in the program should speak of GNU/Linux systems, rather
than calling the whole system "Linux", and should use the term "free
software" rather than "open source".  Since a GNU program is released
under the auspices of GNU, it should not say anything that contradicts
the GNU Project's views.

For a program to be GNU software does not require transferring
copyright to the FSF; that is a separate question.  If you transfer
the copyright to the FSF, the FSF will enforce the GPL for the program
if someone violates it; if you keep the copyright, enforcement will be
up to you.

As the GNU maintainer of the package, please make sure to stay in
touch with the GNU Project.  If we come across a problem relating to
the package, we need to tell you about it, and to discuss with you how
to solve it.  Sometimes we will need to ask you to work with other
maintainers to solve a problem that involves using multiple packages
together.  This probably will happen less than once a year, but please
make sure we can contact you in case it does happen.

For details on all policies and recommendations for GNU packages,
please see the GNU maintainers information, at
http://www.gnu.org/prep/maintain/, and GNU coding standards, at
http://www.gnu.org/prep/standards/.

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

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

[Karl Fogel]

Richard Stallman <rms@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
redirects you to http://bazaar-vcs.org/, via a refresh:

  <meta http-equiv="refresh" content="0; url=http://bazaar-vcs.org/">

but bazaar-vcs.org now redirects to http://bazaar.canonical.com/en/, so
that's where you end up.

So I assume there was a "really pressing reason", because GNU is
actively cooperating with Bazaar in having Bazaar's home page be
somewhere other than gnu.org.  What that reason is, I don't know.

There are other respects in which Bazaar does not meet the normal
standards you quoted, Richard, but I'm not bothering to list them here.
They are easy to discover if you care to devote the investigation time,
and if it's not worth your time it's certainly not worth mine.  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.

-Karl

[1] http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/view/head:/README

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

[Xue Fuqiao]

On Wed, 03 Apr 2013 16:34:31 -0500
Karl Fogel <kfogel@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/

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

[Stephen J. Turnbull]

Xue Fuqiao writes:
 > On Wed, 03 Apr 2013 16:34:31 -0500
 > Karl Fogel <kfogel@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
defects were reported *and fixed* years ago.  The Bazaar pages were
updated at Richard's request to fix references to the "Linux System",
and to give the GNU Project at least as prominent visibility as the
commercial sponsors and users.  Karl's report indicates that many of
those defects have regressed.

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

[Andreas Schwab]

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

> On Wed, 03 Apr 2013 16:34:31 -0500
> Karl Fogel <kfogel@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Xue Fuqiao]

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

> Xue Fuqiao <xfq.free@gmail.com> writes:
> > On Wed, 03 Apr 2013 16:34:31 -0500
> > Karl Fogel <kfogel@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/

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

[Richard Stallman]

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

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

[Leo Liu]

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

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

[Karl Fogel]

Richard Stallman <rms@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!

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

[Richard Stallman]

    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

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

[Richard Stallman]

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

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

[Stefan Monnier]

> 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

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

[Richard Stallman]

    > 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

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

[Stefan Monnier]

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

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

[John Wiegley]

>>>>> Richard Stallman <rms@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

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

[Bastien]

Richard Stallman <rms@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

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

[Richard Stallman]

    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

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

[chad]

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
eyes) to be an actual code change is ~6 months old.

	https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev

I hope that helps.
~Chad

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

[Bastien]

Richard Stallman <rms@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

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

[Michael Welsh Duggan]

"John Wiegley" <johnw@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@md5i.com)

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

[Leo Liu]

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

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

[Giorgos Keramidas]

On 2013-03-27 14:38, Leo Liu <sdl.web@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.

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

[Xue Fuqiao]

On Mon, 1 Apr 2013 00:01:37 +0200
Giorgos Keramidas <gkeramidas@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

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

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

[Giorgos Keramidas]

On 2013-04-01 07:00, Xue Fuqiao <xfq.free@gmail.com> wrote:
> On Mon, 1 Apr 2013 00:01:37 +0200
> Giorgos Keramidas <gkeramidas@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

Of course.  I do not presume to say that Mercurial is going to be around
for more than $FOO, and I didn't post an exhaustive list of projects
using it.  The full list is always available online[1], and it includes
work like Dovecot, the Go and Python programming languages, the whole
Illumos project (previously OpenSolaris), the Linux HA (high
availability project), Mozilla, nginx and many others.

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'.  Projects can and do sometimes change their
VCS, so saying that 'Ubuntu uses bzr so it's safer than X' is a stretch.

[1] http://mercurial.selenic.com/wiki/ProjectsUsingMercurial

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

[Stephen J. Turnbull]

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
a very conservative approach, as much like CVS as possible, others
have been active in DVCS for a long time (eg, Stefan and Miles have
been fiddling with other VCSes since Tom Lord's Arch was a collection
of bash scripts), and Eli himself has gone well beyond "minimal" use
of bzr.  There may be as many people using git to manage their Emacs
branches as there are bzr users, and everybody is agreed that the
current state of Bazaar is unsatisfactory.  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.

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.
The rapid development of "cloud" implementations of git like GitHub
may be a hindrance from Emacs' point of view, though, because they
clearly decrease the pressure for improvements in git's CLI.

Caveat: rms doesn't consider any of that relevant at this point.

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

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Mon, 01 Apr 2013 09:50:29 +0900
> Cc: Xue Fuqiao <xfq.free@gmail.com>, Michael Welsh Duggan <mwd@md5i.com>,
> 	Leo Liu <sdl.web@gmail.com>, emacs-devel@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?

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

[Stephen J. Turnbull]

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.

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

[Stefan Monnier]

> 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

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

[Xue Fuqiao]

On Mon, 1 Apr 2013 01:40:03 +0200
Giorgos Keramidas <gkeramidas@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/

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

[John Wiegley]

>>>>> Giorgos Keramidas <gkeramidas@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

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

[Eli Zaretskii]

> From: "John Wiegley" <johnw@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
this thread.

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

[Karl Fogel]

Eli Zaretskii <eliz@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.

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

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Tue, 02 Apr 2013 14:28:32 -0500
> Cc: John Wiegley <johnw@newartisans.com>, emacs-devel@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).

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

[John Wiegley]

>>>>> Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: John Wiegley <johnw@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.

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

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: John Wiegley <johnw@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

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

[John Wiegley]

>>>>> joakim  <joakim@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

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

[Eli Zaretskii]

> From: John Wiegley <johnw@newartisans.com>
> Date: Thu, 04 Apr 2013 14:15:28 -0500
> 
> >>>>> joakim  <joakim@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.

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

[Sam Steingold]

> * Eli Zaretskii <ryvm@tah.bet> [2013-04-04 21:16:46 +0300]:
>
>> From: John Wiegley <johnw@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.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11300000
http://www.childpsy.net/ http://openvotingconsortium.org
http://pmw.org.il http://palestinefacts.org http://honestreporting.com
Only adults have difficulty with child-proof caps.

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

[Eli Zaretskii]

> From: Sam Steingold <sds@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.

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

[Bastien]

Sam Steingold <sds@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

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

[Xue Fuqiao]

On Fri, 05 Apr 2013 06:34:56 +0200
Bastien <bzg@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/

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

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 2173 bytes --]

>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
contribute".  I have to ask myself, is that really true?

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.

-Barry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Jambunathan K]

Barry Warsaw <barry@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
discord, if such moves are considered for what they are - political.

ps: Please, don't flame me for expressing my views here.

> -Barry

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

[Stefan Monnier]

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

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

[Xue Fuqiao]

On Sat, 06 Apr 2013 21:09:03 -0400
Stefan Monnier <monnier@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/

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

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: John Wiegley <johnw@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.

I did the same with bzr, but now I'd much rather be using Git. On the
other hand, I don't have write privs in the Emacs repository anyway (I
only use bzr for download), so I send patches to other people; they are
the ones that have to actually deal with bzr commits.

-- 
-- Stephe

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]

On 4/4/2013 4:08 PM, Stephen Leake wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> From: John Wiegley <johnw@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.

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, then git
should emerge the victor due to its massive inertia.

So why are we still arguing about this? Why aren't we switching to git?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

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

[Stephen J. Turnbull]

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.

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

[Wojciech Meyer]

"Stephen J. Turnbull" <stephen@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
Emacswiki but maybe documenting the internals would be good. On other
hand Emacs itself does have certain other threshold to get the
contributions working, it's a primary GNU project (which personally for
me was the showstopping problem, and I didn't realise at time it will
take that much time to get my papers done in my company, and eventually
I didn't contribute, and still don't know why) and it has certain degree
of tooling and knowledge required.

So, I think contributing to Emacs is what many people dreamed about, but
there shouldn't be any unneeded barriers for that. (I don't even count
FSF paper work, because I believe it's extremely important to get it
done for the sake of being fair with the ideology). I think some
people are convinced enough to even use Bzr to get the pleasure of
contributing to project like Emacs. :-)

Cheers,
--
Wojciech
http://danmey.org

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

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

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

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: John Wiegley <johnw@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
mean you're doing anything qualitatively different from him.  Think of
all the free software projects you like & use but don't contribute to,
even when you've found a bug.  You're engaging in the same calculation:
the entry cost of fixing that bug is too high, so you choose to spend
your time elsewhere.  But sometimes, you might mail a project and say
"If your build process [or whatever] were easier, I'd be more likely to
contribute."  This would be no more an ultimatum than what John said.

-K

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

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: John Wiegley <johnw@newartisans.com>,  emacs-devel@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.

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

[Lennart Borgman]

On Fri, Apr 5, 2013 at 5:14 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Karl Fogel <kfogel@red-bean.com>
>> Cc: John Wiegley <johnw@newartisans.com>,  emacs-devel@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.

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

[Pascal J. Bourguignon]

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

>>>>>> Giorgos Keramidas <gkeramidas@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 {}.

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

[Stephen J. Turnbull]

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
CLI.  But I think that that desideratum will be more than adequately
satisfied via Lisp interfaces to git[3].  OTOH, there is a large
contingent of Emacs developers whose preferred VCS is git for various
reasons.

Of course, I've long been a git advocate, so the above is a selective
account of the merits and demerits.  Nevertheless, HTH.

Footnotes: 
[1]  IMHO YMMV.

[2]  Which criticism I admit I have no sympathy for.  Of the plethora
of commands, I admit I use quite a few (16 = init, add, rm, mv,
commit, status, log, diff, pull, push, branch, checkout, reset, gitk,
tag, help) frequently, but I rarely use options other than -m and -F
to commit, -b to checkout, and -<number> to log.  I suppose you
noticed "help", well, (a) I advise people on git a lot and need to
refer to help for workflows I don't use, and (b) I grant that
infrequently used commands like rebase are indeed complex, but their
power more than justifies the time to refer to help.  But I suppose
that's just me. ;-)

     I think that one big problem is not the CLI per se, but that
people who have a non-git mental model of VCS have great trouble
making sense of the way branch, checkout, and reset interact.  Also,
many people dislike git's practice of counting versions "backward"
from HEAD rather than "forward" from the repository root.

[3]  You've heard of vc.el and magit, I suppose?

[4]  Rename and first-class directory support.

[5]  The analogy is not perfect, of course, because a cons can have
only one cdr, while to implement merges a git commit is allowed to
have multiple parents.

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

[John Wiegley]

>>>>> Michael Welsh Duggan <mwd@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
   as possible.

 - A system with a good integration story in Emacs itself (magit!), since this
   is the environment many of us will be working in.

 - A system with lots and lots of external resources we can point people to,
   with an active and helpful community, so that we ourselves are never bogged
   down answering question about said system.

I think Git presents us with a pretty good answer to each of these points, in
terms of Emacs development.  Bazaar has an answer to some of them as well, but
I think no other system is as resoundingly in our favor as Git on almost every
point.

John

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

[Romain Francoise]

"John Wiegley" <johnw@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.

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

[Jordi Gutiérrez Hermoso]

On 27 March 2013 00:15, Michael Welsh Duggan <mwd@md5i.com> wrote:
> "John Wiegley" <johnw@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
of these two versions of gnulib:

    time git clone git://git.sv.gnu.org/gnulib.git
    time hg clone http://hg.savannah.gnu.org/hgweb/octave/gnulib-hg

Both are on the same server, so at least that's not a factor. Note
that the hg link is actually web browsable. Same url for browsing as
for cloning!

I very much heartily endorse hg for Emacs. But sadly, this is a
minority opinion. I do want Emacs to move away from bzr. If you think
my Mercurial advocacy is lunacy, at least consider me an ally in
moving Emacs away from bzr. At least nowadays hg-git works well for
me, and I'll maintain an hg mirror for Emacs for anyone who wants to
use it.

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

Too late? :-)

- Jordi G. H.

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

[Carsten Dominik]

On 26 mrt. 2013, at 20:38, John Wiegley <johnw@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

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

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

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 */

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

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

[Ted Zlatanov]

On Wed, 27 Mar 2013 10:09:34 +0100 Julien Danjou <julien@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

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

[David Engster]

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
least not until someone shows me how (and don't just say "submodules",
please ;-) ).

-David

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

[Ted Zlatanov]

On Wed, 27 Mar 2013 11:36:44 +0100 David Engster <deng@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

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

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

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

[Stefan Monnier]

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

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

[David Engster]

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

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

[Stephen Leake]

Stefan Monnier <monnier@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

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

[Stephen Leake]

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

> Stefan Monnier <monnier@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

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

[Stephen J. Turnbull]

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----- ...
        \         /    \/    \
         \       /     /\     \
branch    a--b--c-----d--e-----f-- ...

and the merge at <f> can be a monstrosity because the structure of the
DAG is little help in disentangling conflicts: the most recent common
ancestor of <f> is <c>, and there are 4 "long" paths between them,
increasing the expected number of conflicts.  If Monotone does handle
these gracefully, that would be *really* cool!

 > 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

Could be, but I really don't see anything on that page that other
DVCSes don't have, and the note about "the special case of file
content conflicts" which invoke an external merge tool looks pretty
ordinary.  I suspect that --resolve-conflicts-file does something
similar to git's rerere command, or perhaps git's interactive rebase
command.

Steve

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

[Stephen Leake]

"Stephen J. Turnbull" <stephen@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-- ...
>
> and the nature of such workflows is that typically conflicts are
> relatively few; you do different things in different branches.

Yes, that is typical.

> 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----- ...
>         \         /    \/    \
>          \       /     /\     \
> branch    a--b--c-----d--e-----f-- ...
>
> and the merge at <f> can be a monstrosity because the structure of the
> DAG is little help in disentangling conflicts: the most recent common
> ancestor of <f> is <c>, and there are 4 "long" paths between them,
> increasing the expected number of conflicts.  If Monotone does handle
> these gracefully, that would be *really* cool!

We often get criss-cross merges with short paths; people do work on the
same branch in parallel.

You are correct that sorting out the conflicts when the path to the
ancestor is long is inherently hard. monotone/DVC presents the relevant
files in a nice way, and allows the user to take their time in sorting
things out. The conflict resolution state is saved on the disk, so you
don't have to resolve all conflicts in one interactive session.

>  > 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
>
> Could be, but I really don't see anything on that page that other
> DVCSes don't have, and the note about "the special case of file
> content conflicts" which invoke an external merge tool looks pretty
> ordinary.  I suspect that --resolve-conflicts-file does something
> similar to git's rerere command, or perhaps git's interactive rebase
> command.

Hmm. According to
https://www.kernel.org/pub/software/scm/git/docs/git-rerere.html, 'git
rerere' is for conflicts that happen again on subsequent merges.
monotone (in recent heads, not in the current release) has that for
dropped/modified conflicts; I haven't felt the need for it for other
types of conflicts, but it would be easy to add.

--resolve-conflicts-file specifies the resolutions for one merge; it
does not make sense to save the whole file for a subsequent merge. It
might make sense to save parts of it.

'git rebase' is similar to 'mtn merge'; 'git rebase --continue' appears
to support a "merge" that stops partway thru due to a conflict, which
the user must then resolve before resuming the merge, and getting to the
next conflict.

So the user does not see all conflicts at once, which makes the conflict
resolution harder. It is especially frustrating if you don't know how
many conflicts there are; how much time will be needed to finish the
merge. Is there a git command that lists all conflicts in a rebase
before starting?

When git rebase hits a conflict, it creates a local file with CVS-style
conflict markers. monotone just notes the two file versions, and the DVC
front end pops up an Emacs ediff; that's better than Emacs' CVS conflict
mode.

git then requires 'git add' commit to indicate the conflict resolution.
This leaves the workspace in an odd state; is there a git command that
indicates the workspace is in the middle of an interactive rebase?
Suppose you are interrupted, and come back in a week; can you tell what
state the rebase is in? In monotone, all of the conflict resolution is
done outside the workspace (in <root>/_MTN/resolutions/*), and it is
always clear what is going on.

These are not fundamentally different approaches (they do solve the same
problem), but the details can matter when you do this a lot. I assume
git could be enhanced to be more similar to monotone in this area; I'll
probably be forced to do that when monotone finally dies :(.

-- 
-- Stephe

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

[Andreas Schwab]

Stephen Leake <stephen_leake@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[David Engster]

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
easily script doing 'bzr --take-this resolve' on those files.

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. Doing this by
hand is a nightmare, so I've written a package for this
(cedet-emacs-merge.el in CEDET trunk). It generates this list, display
them nicely, lets me test the patches, show conflicts, generates commit
messages, and so on. Most importantly, it keeps track of things I have
applied or ignored and saves this state in the repository as a file
which I can load later.

When I've cherry-picked all the commits to 'from-emacs'. I also have to
merge it into 'to-emacs' before merging 'trunk', as I don't want things
in my diff for CEDET->Emacs which originated from Emacs in the first
place. I guess this is where the criss-crossing comes from.

Yep, it's messy. But I'm used to it now. The most time consuming thing
is fixing ChangeLogs (we don't have any in CEDET and generate them from
commit logs).

-David

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

[Christopher Schmidt]

David Engster <deng@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

Re: Abolishing ChangeLog files

[Thierry Volpiatto]

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

> David Engster <deng@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:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Abolishing ChangeLog files

[Richard Stallman]

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

Re: Abolishing ChangeLog files

[Aidan Gauland]

Richard Stallman <rms@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

Re: Abolishing ChangeLog files

[Stefan Monnier]

> 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

Re: Abolishing ChangeLog files

[Richard Stallman]

    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

Re: Abolishing ChangeLog files

[Paul Eggert]

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

Re: Abolishing ChangeLog files

[Stefan Monnier]

> 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

Re: Abolishing ChangeLog files

[Steve Youngs]

* Richard Stallman <rms@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?

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

Re: Abolishing ChangeLog files

[Richard Stallman]

      > 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

Re: Abolishing ChangeLog files

[Steve Youngs]

* Richard Stallman <rms@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). 

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

Re: Abolishing ChangeLog files

[Eli Zaretskii]

> From: Steve Youngs <steve@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.

Re: Abolishing ChangeLog files

[John Wiegley]

>>>>> Steve Youngs <steve@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

Re: Abolishing ChangeLog files

[Steve Youngs]

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

  >>>>>> Steve Youngs <steve@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@sxemacs.org>---|

Re: Abolishing ChangeLog files

[Richard Stallman]

    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

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

[Carsten Dominik]

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

> David Engster <deng@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

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


Thanks to Matt Lundin for reporting bugs in this area.
-------------------------------------------------------------------------------------------


Indeed, this process does get rid of many conflicts, because the adding of text to the
beginning of a file (like ChangeLog) often causes merge conflicts.  And it avoids a lot of duplicate work.

- Carsten

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

[Alan Mackenzie]

Hello, Christopher.

On Thu, Mar 28, 2013 at 09:55:29AM +0000, Christopher Schmidt wrote:
> David Engster <deng@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.

>         Christopher

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Abolishing ChangeLog files

[David Engster]

Alan Mackenzie writes:
> On Thu, Mar 28, 2013 at 09:55:29AM +0000, Christopher Schmidt wrote:
>> David Engster <deng@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
  five different ChangeLogs: etc/, admin/, doc/misc, lisp/, and finally
  lisp/cedet),

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

Much of this stuff could be automated, though. I just didn't have time
yet to implement all this. Maybe we could work together with the Org
people on that; while we use bzr, I guess some of the code could be
shared.

-David

Re: Abolishing ChangeLog files

[Steve Youngs]

* David Engster <deng@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.

The biggest obstacle is getting your developers to DTRT at commit time,
and once you get that down pat, it is smooth sailing from there on. :-)


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

Re: Abolishing ChangeLog files

[Thierry Volpiatto]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Christopher.
>
> On Thu, Mar 28, 2013 at 09:55:29AM +0000, Christopher Schmidt wrote:
>> David Engster <deng@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.

Because bzr log take ages to popup, I guess it is one reason you relay
on changelog files.

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


>>         Christopher

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

Re: Abolishing ChangeLog files

[John Wiegley]

>>>>> Alan Mackenzie <acm@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

Re: Abolishing ChangeLog files

[Steve Youngs]

* Alan Mackenzie <acm@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@sxemacs.org>---|

Re: Abolishing ChangeLog files

[Stefan Monnier]

> 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

Re: Abolishing ChangeLog files

[Eli Zaretskii]

> From: Stefan Monnier <monnier@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.)

Re: Abolishing ChangeLog files

[Eli Zaretskii]

> Date: Thu, 28 Mar 2013 18:34:41 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@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.

Re: Abolishing ChangeLog files

[Dmitry Gutov]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@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
shows (900ms for Bazaar and 200ms for Git).

In my experience, Bzr is especially slow when showing log for a subtree
or a specific file.

Re: Abolishing ChangeLog files

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 28 Mar 2013 21:20:44 +0400
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@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,
anyway.

Re: Abolishing ChangeLog files

[Dmitry Gutov]

On 28.03.2013 21:34, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Thu, 28 Mar 2013 21:20:44 +0400
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@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.

>> 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. But here's an example command:

   git log lisp\progmodes\ruby-mode.el | less

It takes about 300ms on the first run and is instantaneous after that.

If I call the respective command in a Bazaar repository, it takes about 
4 seconds on every run, Bazaar doesn't seem to do any caching here. Note 
that I'm using version 2.5.1, it could be better in the latest beta.

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. Of course, most of 
that is due to the server being overloaded.

Speaking of removing changelogs, I think the foremost challenge is 
keeping the format. We don't have anything similar to 
`add-change-log-entry' for the log-edit buffer, and I'm not sure how 
that would even work.

Re: Abolishing ChangeLog files

[Eli Zaretskii]

> Date: Fri, 29 Mar 2013 01:04:35 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: monnier@iro.umontreal.ca, emacs-devel@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
> 
> It takes about 300ms on the first run and is instantaneous after that.

Not here:

  $ time git log lisp/progmodes/ruby-mode.el > /dev/null

  real    0m5.140s
  user    0m0.015s
  sys     0m0.000s

  D:\gnu\bzr\emacs\msys-build>timep bzr log lisp\progmodes\ruby-mode.el > nul

  real    00h00m04.281s
  user    00h00m04.078s
  sys     00h00m00.218s

Entirely comparable.  And re-running the commands doesn't change the
times, so I don't think any caching is involved.

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

But we have been all through this, time and again.  The real numbers
don't convince anyone.  It's a religious argument since day one.

Re: Abolishing ChangeLog files

[Dmitry Gutov]

On 29.03.2013 1:29, Eli Zaretskii wrote:
>> Date: Fri, 29 Mar 2013 01:04:35 +0400
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Cc: monnier@iro.umontreal.ca, emacs-devel@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.

Since you don't seem inclined to distribute it, you won't get exact 
numbers from me.

>> But here's an example command:
>>
>>     git log lisp\progmodes\ruby-mode.el | less
>>
>> It takes about 300ms on the first run and is instantaneous after that.
>
> Not here:
>
>    $ time git log lisp/progmodes/ruby-mode.el > /dev/null
>
>    real    0m5.140s
>    user    0m0.015s
>    sys     0m0.000s
>
>    D:\gnu\bzr\emacs\msys-build>timep bzr log lisp\progmodes\ruby-mode.el > nul
>
>    real    00h00m04.281s
>    user    00h00m04.078s
>    sys     00h00m00.218s
>
> Entirely comparable.  And re-running the commands doesn't change the
> times, so I don't think any caching is involved.

That's a weak reply.

Since I get much better numbers with Git, it just means that you need to 
install a newer version, do 'git gc', or whatever. On the other hand, 
you get the same numbers with Bazaar, which confirms that Bazaar can't 
do better.

For the record:

C:\Users\gutov\vc\emacs-git>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.

I mean that whenever I need to do a commit in the Emacs repository, 'bzr 
update' takes at least 30 seconds or so, even when the difference 
between the local and remote heads is a couple of commits.

I don't see this kind of problem with Git, but maybe I just haven't 
tried it with a repository hosted on the same server as Bazaar one.

Re: Abolishing ChangeLog files

[Eli Zaretskii]

> Date: Fri, 29 Mar 2013 02:42:51 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: monnier@iro.umontreal.ca, emacs-devel@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.
> 
> I mean that whenever I need to do a commit in the Emacs repository, 'bzr 
> update' takes at least 30 seconds or so, even when the difference 
> between the local and remote heads is a couple of commits.
> 
> I don't see this kind of problem with Git, but maybe I just haven't 
> tried it with a repository hosted on the same server as Bazaar one.

I did, just now:

  D:\gnu\bzr\emacs\trunk>timep bzr up
  Connected (version 2.0, client OpenSSH_5.9)
  Authentication (publickey) successful!
  Secsh channel 1 opened.
   M  nt/ChangeLog
   M  nt/config.nt
   M  src/ChangeLog
   M  src/makefile.w32-in
  All changes applied successfully.
  Updated to revision 112175 of branch bzr+ssh://eliz@bzr.savannah.gnu.org/emacs/trunk

  real    00h00m24.890s
  user    00h00m01.125s
  sys     00h00m00.203s

  $ time git pull
  remote: Counting objects: 17, done.
  remote: Compressing objects: 100% (10/10), done.
  remote: Total 10 (delta 8), reused 0 (delta 0)
  Unpacking objects: 100% (10/10), done.
  From git://git.savannah.gnu.org/emacs
     6dd8f02..830b8b3  master     -> origin/master
     6dd8f02..830b8b3  trunk      -> origin/trunk
  Updating 6dd8f02..830b8b3
  Fast-forward
   nt/ChangeLog        | 6 ++++++
   nt/config.nt        | 4 ++--
   src/ChangeLog       | 5 +++++
   src/makefile.w32-in | 2 ++
   4 files changed, 15 insertions(+), 2 deletions(-)

  real    0m27.516s
  user    0m0.015s
  sys     0m0.000s

Re: Abolishing ChangeLog files

[Eli Zaretskii]

> Date: Fri, 29 Mar 2013 08:45:44 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> > Date: Fri, 29 Mar 2013 02:42:51 +0400
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > CC: monnier@iro.umontreal.ca, emacs-devel@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.)

Re: Abolishing ChangeLog files

[Thierry Volpiatto]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 29 Mar 2013 08:45:44 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> 
>> > Date: Fri, 29 Mar 2013 02:42:51 +0400
>> > From: Dmitry Gutov <dgutov@yandex.ru>
>> > CC: monnier@iro.umontreal.ca, emacs-devel@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
| 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).

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

Re: Abolishing ChangeLog files

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@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.

Re: Abolishing ChangeLog files

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: Thierry Volpiatto <thierry.volpiatto@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?

Re: Abolishing ChangeLog files

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Thierry Volpiatto <thierry.volpiatto@gmail.com>,
>     emacs-devel@gnu.org
> Date: Fri, 29 Mar 2013 17:38:10 +0900
> 
> Eli Zaretskii writes:
>  > > From: Thierry Volpiatto <thierry.volpiatto@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.

Re: Abolishing ChangeLog files

[Stephen J. Turnbull]

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.

Re: Abolishing ChangeLog files

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: emacs-devel@gnu.org,
>     thierry.volpiatto@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.

Re: Abolishing ChangeLog files

[Thierry Volpiatto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Stephen J. Turnbull" <stephen@xemacs.org>
>> Cc: Thierry Volpiatto <thierry.volpiatto@gmail.com>,
>>     emacs-devel@gnu.org
>> Date: Fri, 29 Mar 2013 17:38:10 +0900
>> 
>> Eli Zaretskii writes:
>>  > > From: Thierry Volpiatto <thierry.volpiatto@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,
crash, workaround to find, etc..., so no sorry.

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

Re: Abolishing ChangeLog files

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,  emacs-devel@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?

Re: Abolishing ChangeLog files

[Thierry Volpiatto]

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

> Eli Zaretskii writes:
>  > > From: Thierry Volpiatto <thierry.volpiatto@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 ?!
  
-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Abolishing ChangeLog files

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@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.

Re: Abolishing ChangeLog files

[Stephen J. Turnbull]

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.

Re: Abolishing ChangeLog files

[Dmitry Gutov]

On 29.03.2013 10:10, Eli Zaretskii wrote:
>> Date: Fri, 29 Mar 2013 08:45:44 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: monnier@iro.umontreal.ca, emacs-devel@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
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. If you redirect 
its output to 'less' (like I did in the command I sent in one of the 
previous messages), you'll see that the viewer opens near instantly, and 
allows you to view the latest commits while the VCS fetches the older 
data. Same thing happens when a user calls `vc-print-log' in Emacs, and 
it makes all the difference.

Here's a more striking example. Show the last 40 commits:

emacs-git-savannah>timep git log -40 lisp\progmodes\ruby-mode.el > NUL

real    00h00m00.226s
user    00h00m00.015s
sys     00h00m00.000s

emacs-bzr\trunk>timep bzr log -l 40 lisp\progmodes\ruby-mode.el > NUL

real    00h00m08.273s
user    00h00m07.878s
sys     00h00m00.265s

Git is finally fast, but Bazaar is as slow as when it retrieves the full 
history.

 >> I don't see this kind of problem with Git, but maybe I just haven't
 >> tried it with a repository hosted on the same server as Bazaar one.

 > I did, just now: (...)

I tried it, too, and here Git wins hands-down.

Here's how long it takes to update both when they are already up-to-date 
(staging a situation when they're the same number of revisions 
out-of-date is harder):

emacs-git-savannah>timep git pull
Already up-to-date.

real    00h00m02.139s
user    00h00m00.000s
sys     00h00m00.031s

emacs-bzr\trunk>timep bzr update
Дерево в актуальной ревизии 112180 ветви 
bzr+ssh://dgutov@bzr.savannah.gnu.org/emacs/trunk


real    00h00m09.963s
user    00h00m00.343s
sys     00h00m00.202s


Before that, I updated this Bazaar clone from a several-days-old 
revision, and it took 4 minutes. 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), it will likely be faster.

emacs-bzr\trunk>timep bzr update
+N  lisp/eshell/em-tramp.el
  M  ChangeLog
  M  admin/CPP-DEFINES
  M  autogen/config.in
  M  autogen/configure
  M  configure.ac
  M  doc/lispref/ChangeLog
  M  doc/lispref/compile.texi
  M  doc/misc/eshell.texi
  M  etc/NEWS
...
...
...
  M  src/xselect.c
  M  src/xsmfns.c
  M  src/xterm.c
All changes applied successfully.
Обновлено до ревизии 112180 ветви 
bzr+ssh://dgutov@bzr.savannah.gnu.org/emacs/trunk

real    00h04m11.939s
user    00h00m06.520s
sys     00h00m01.466s

Re: Abolishing ChangeLog files

[Eli Zaretskii]

> Date: Fri, 29 Mar 2013 19:07:50 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org, Stefan Monnier <monnier@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@gnu.org>
> >> Cc: monnier@iro.umontreal.ca, emacs-devel@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
> 
> 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?

>  > I did, just now: (...)
> 
> I tried it, too, and here Git wins hands-down.
> 
> Here's how long it takes to update both when they are already up-to-date 
> (staging a situation when they're the same number of revisions 
> out-of-date is harder):
> 
> emacs-git-savannah>timep git pull
> Already up-to-date.
> 
> real    00h00m02.139s
> user    00h00m00.000s
> sys     00h00m00.031s
> 
> emacs-bzr\trunk>timep bzr update
> Дерево в актуальной ревизии 112180 ветви 
> bzr+ssh://dgutov@bzr.savannah.gnu.org/emacs/trunk
> 
> 
> real    00h00m09.963s
> user    00h00m00.343s
> sys     00h00m00.202s

So you wasted the whole of 7 sec to know that your tree is up to
date.  Big deal!

> Before that, I updated this Bazaar clone from a several-days-old 
> revision, and it took 4 minutes.

Your network needs an urgent upgrade.

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

Re: Abolishing ChangeLog files

[Dmitry Gutov]

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 
they are usually the ones I need. If I want the last, I can at least do 
some reading and scrolling while they're being retrieved.

And you shouldn't underestimate the perception of being instantaneous. 
If you were looking for a reason why people think that Bazaar is too 
slow, this one's a very plausible culprit.

>>   > I did, just now: (...)
>>
>> I tried it, too, and here Git wins hands-down.
>>
>> Here's how long it takes to update both when they are already up-to-date
>> (staging a situation when they're the same number of revisions
>> out-of-date is harder):
>>
>> emacs-git-savannah>timep git pull
>> Already up-to-date.
>>
>> real    00h00m02.139s
>> user    00h00m00.000s
>> sys     00h00m00.031s
>>
>> emacs-bzr\trunk>timep bzr update
>> Дерево в актуальной ревизии 112180 ветви
>> bzr+ssh://dgutov@bzr.savannah.gnu.org/emacs/trunk
>>
>>
>> real    00h00m09.963s
>> user    00h00m00.343s
>> sys     00h00m00.202s
>
> So you wasted the whole of 7 sec to know that your tree is up to
> date.  Big deal!

You can reply "big deal" to almost any speed comparison. But yes, Bazaar 
took 7 seconds longer and, measuring relatively, was 4 times slower. 
It's annoying, and it gives a bad impression.

And it's even slower when there's actually stuff to update.

>> Before that, I updated this Bazaar clone from a several-days-old
>> revision, and it took 4 minutes.
>
> Your network needs an urgent upgrade.

My bandwidth definitely exceeds the connection speeds reported by Bazaar 
when it's doing its thing.

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

Re: Abolishing ChangeLog files

[Eli Zaretskii]

> Date: Fri, 29 Mar 2013 19:58:58 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org, monnier@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.

Re: Abolishing ChangeLog files

[chad]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]


On 29 Mar 2013, at 08:58, Dmitry Gutov <dgutov@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:

; git clone git://git.savannah.gnu.org/emacs
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

[-- Attachment #2: Type: text/html, Size: 1525 bytes --]

Re: Abolishing ChangeLog files

[Dmitry Gutov]

On 29.03.2013 9:45, Eli Zaretskii wrote:
>> Date: Fri, 29 Mar 2013 02:42:51 +0400
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> CC: monnier@iro.umontreal.ca, emacs-devel@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.

Re: Abolishing ChangeLog files

[Stefan Monnier]

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

Re: Abolishing ChangeLog files

[Nikolai Weibull]

On Thu, Mar 28, 2013 at 1:41 PM, Stefan Monnier
<monnier@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”.

Re: Abolishing ChangeLog files

[Stefan Monnier]

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

Re: Abolishing ChangeLog files

[Nikolai Weibull]

On Sat, Mar 30, 2013 at 3:20 AM, Stefan Monnier
<monnier@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”.

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

[Stefan Monnier]

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

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

[David Engster]

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

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

[Stephen J. Turnbull]

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

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

[David Engster]

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

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

[joakim]

David Engster <deng@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

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

[Stefan Monnier]

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

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

[Kolo Rahl]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1562 bytes --]

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

[Stefan Monnier]

> 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

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

[Stephen Leake]

Stefan Monnier <monnier@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