Git mirrors

Git mirrors

[Lars Magne Ingebrigtsen]

Am I the only one getting frustrated by people using a git mirror of
Emacs, and then sending bug reports about what they find?  Something
that has invariably been fixed in bzr Emacs days or weeks ago, which I
find out after sending ten mail messages back and forth?

Well, it's mostly in a Gnus context I'm getting those kinds of reports,
so perhaps I'm the only one.

But it's getting to a point where I'm kinda wishing that people setting
up git mirrors would just stop doing that.  Or failing that, keep the
mirrors up-to-date.  Is it so impossible to set up an automatic bzr->git
gateway?  One that polls and pushes, say, every ten minutes?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Git mirrors

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> Am I the only one getting frustrated by people using a git mirror of
> Emacs, and then sending bug reports about what they find?

Nope. You make the points very well.
I also dislike getting bug reports "I see this problem in [git] revision
000000deadbeef00000", which means nothing to me.

But now cue people moaning about how they don't like bzr and simply must
use git because of [awesome feature].

Re: Git mirrors

[chad]

On Oct 6, 2011, at 1:58 PM, Glenn Morris wrote:

> Lars Magne Ingebrigtsen wrote:
> 
>> Am I the only one getting frustrated by people using a git mirror of
>> Emacs, and then sending bug reports about what they find?
> 
> Nope. You make the points very well.

These are the (only) reasons that I use bzr, and I'm probably not
alone in this case.  While people are used to git, and can be
forgiven for falling in love with git after living with cvs or
subversion, it's really not that hard to use bzr.

Can we add some sort of hook or check in report-emacs-bug to
cover this case?  Perhaps if emacs knows it was built from a
repository instead of a release (there are 4 parts to
emacs-version), then it inserts a message like ``Thank you for
helping with Emacs!  Unless you are using the GNU Bazaar
repository of emacs, you might wish to check the latest source
via bazaar or at http://bzr.savannah.gnu.org/lh/emacs/trunk
before reporting a problem.''?

Of course, if we ever decided to include a bzr revno/etc in the
environment, that could also help.

*Chad

Re: Git mirrors

[John Wiegley]

>>>>> chad  <yandros@MIT.EDU> writes:

> These are the (only) reasons that I use bzr, and I'm probably not alone in
> this case.  While people are used to git, and can be forgiven for falling in
> love with git after living with cvs or subversion, it's really not that hard
> to use bzr.

Not really that hard?  Let's put it this way: If Bazaar were the _only_ way I
could follow Emacs development and contribute back code, I'd simply stop doing
so and pay attention only to releases from now on.  Bazaar is nasty to use,
especially when I have hundreds of Git repositories on my machine and exactly
one Bazaar repository.  I don't like it, and there's not a good Emacs
interface for it (I tried DVC and did not like the experience at all); while
Git has some very beautiful GUIs, Magit, and lots and lots of community-built
tools written around Git that make my day-day operations much easier.

John

Re: Git mirrors

[David Reitter]

On Oct 6, 2011, at 5:16 PM, chad wrote:

> Of course, if we ever decided to include a bzr revno/etc in the
> environment, that could also help.


Excellent, constructive idea!


On Oct 6, 2011, at 4:50 PM, Lars Magne Ingebrigtsen wrote:
> 
>  Or failing that, keep the
> mirrors up-to-date.  Is it so impossible to set up an automatic bzr->git
> gateway?  One that polls and pushes, say, every ten minutes?


That would be very much appreciated.
Perhaps the person doing the updates could elaborate whether manual interventions are needed.


On Oct 6, 2011, at 5:58 PM, John Wiegley wrote:

> Not really that hard?  Let's put it this way: If Bazaar were the _only_ way I
> could follow Emacs development and contribute back code, I'd simply stop doing
> so and pay attention only to releases from now on.

+1

I would contribute more to the NS port rather then making armchair comments on this mailing list if it could be done with my tool of choice.
The NS port would have a fullscreen mode by now, for example, with correct frame-parameter integration.  (We've had it in Aquamacs for a long time!)

Re: Git mirrors

[Glenn Morris]

David Reitter wrote:

> On Oct 6, 2011, at 5:58 PM, John Wiegley wrote:
>
>> If Bazaar were the _only_ way I could follow Emacs development and
>> contribute back code, I'd simply stop doing so and pay attention only
>> to releases from now on.
>
> +1
>
> I would contribute more to the NS port rather then making armchair
> comments on this mailing list if it could be done with my tool of
> choice. The NS port would have a fullscreen mode by now, for example,
> with correct frame-parameter integration. (We've had it in Aquamacs
> for a long time!)

Comments like these are really depressing.

Perhaps you could post the patch and its attribution to bug-gnu-emacs so
that someone else can review it for possible application after the
feature freeze. (I won't be able to do this myself because I won't be
able to test it or judge the technical merits.)

Then at least something productive may come of
yet-another-VCS-derail-on-emacs-devel.

Re: Git mirrors

[Julien Danjou]

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

On Fri, Oct 07 2011, Glenn Morris wrote:

> Then at least something productive may come of
> yet-another-VCS-derail-on-emacs-devel.

Git is so much better that projects using it don't have such derails.

(Sorry :-)

-- 
Julien Danjou

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

Re: Git mirrors

[Tim Cross]

On Fri, Oct 7, 2011 at 9:05 AM, David Reitter <david.reitter@gmail.com> wrote:
> On Oct 6, 2011, at 5:16 PM, chad wrote:
>
>> Of course, if we ever decided to include a bzr revno/etc in the
>> environment, that could also help.
>
>
> Excellent, constructive idea!
>
>

yep, I agree it is a good idea. It has also been suggested numerous
times before, but rejected for one reason or another.

From memory, the main reason was to do with having different build
paths/processes depending on whether you build from version controlled
code or something else, such as a tar archive/export of the code.

I suspect there will be some subtle issues to resolve, but the benefit
of bug reports/discussions including emacs-version which also includes
the revno or commit number would e very useful - at least I've found
such info useful in other projects and would assume the same would be
true of emacs.

Tim


> On Oct 6, 2011, at 4:50 PM, Lars Magne Ingebrigtsen wrote:
>>
>>  Or failing that, keep the
>> mirrors up-to-date.  Is it so impossible to set up an automatic bzr->git
>> gateway?  One that polls and pushes, say, every ten minutes?
>
>
> That would be very much appreciated.
> Perhaps the person doing the updates could elaborate whether manual interventions are needed.
>
>
> On Oct 6, 2011, at 5:58 PM, John Wiegley wrote:
>
>> Not really that hard?  Let's put it this way: If Bazaar were the _only_ way I
>> could follow Emacs development and contribute back code, I'd simply stop doing
>> so and pay attention only to releases from now on.
>
> +1
>
> I would contribute more to the NS port rather then making armchair comments on this mailing list if it could be done with my tool of choice.
> The NS port would have a fullscreen mode by now, for example, with correct frame-parameter integration.  (We've had it in Aquamacs for a long time!)
>



-- 
Tim Cross
Phone: 0428 212 217

Re: Git mirrors

[Burton Samograd]

Hello,

> These are the (only) reasons that I use bzr, and I'm probably not
> alone in this case.  While people are used to git, and can be
> forgiven for falling in love with git after living with cvs or
> subversion, it's really not that hard to use bzr.

My bug repost is the cause for Lars to send his original email.  I tried
pulling the bzr tree using the instructions on savanna and it just hung,
so I tried the git repository and it worked fine.  It's not that it's
not that hard to use, it just that it didn't work for me when I tried.

I wasn't on this list back then so I didn't report the problem, but I
would now.

--
Burton Samograd

Re: Git mirrors

[Eli Zaretskii]

> From: Burton Samograd <bsamograd@interalia.com>
> Date: Fri, 07 Oct 2011 12:43:36 -0600
> 
> I tried pulling the bzr tree using the instructions on savanna and
> it just hung, so I tried the git repository and it worked fine.

The usual recipe to overcome this problem is to use a different URL
for the initial "bzr branch" command:

  bzr branch nosmart+bzr://bzr.savannah.gnu.org/emacs/trunk

This is mentioned on this page:

  http://www.emacswiki.org/emacs/BzrForEmacsDevs

This URL is not recommended to be used beyond the initial branch
command, since the "smart" server behavior makes later updates from
upstream much faster.  But it turns out that for relatively slow
network connections, the "smart" server makes things worse, because it
tries to optimize what's being sent down the wire, when eventually
everything needs to be sent and nothing can be optimized.  So
disabling the smart server for this one command speeds things up.

Re: Git mirrors

[Burton Samograd]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Burton Samograd <bsamograd@interalia.com>
>> Date: Fri, 07 Oct 2011 12:43:36 -0600
>> 
>> I tried pulling the bzr tree using the instructions on savanna and
>> it just hung, so I tried the git repository and it worked fine.
>
> The usual recipe to overcome this problem is to use a different URL
> for the initial "bzr branch" command:
>
>   bzr branch nosmart+bzr://bzr.savannah.gnu.org/emacs/trunk
>
> This is mentioned on this page:
>
>   http://www.emacswiki.org/emacs/BzrForEmacsDevs
>
> This URL is not recommended to be used beyond the initial branch
> command, since the "smart" server behavior makes later updates from
> upstream much faster.  But it turns out that for relatively slow
> network connections, the "smart" server makes things worse, because it
> tries to optimize what's being sent down the wire, when eventually
> everything needs to be sent and nothing can be optimized.  So
> disabling the smart server for this one command speeds things up.

Thanks for the tip.  I just tried again and had no problems with getting
the bzr branch and after rebuilding found my gnus problem to be gone (as
Lars pointed out).  Sorry Lars for wasting your time.

--
Burton Samograd

Re: Git mirrors

[Óscar Fuentes]

Glenn Morris <rgm@gnu.org> writes:

> Lars Magne Ingebrigtsen wrote:
>
>> Am I the only one getting frustrated by people using a git mirror of
>> Emacs, and then sending bug reports about what they find?
>
> Nope. You make the points very well.

So you expect from users to fetch and build the very latest sources
before sending a bug report? (assuming that the bug is easily
reproducible)

... to see how, in most cases, the bug report is left resting on the
database for months until someone has some spare time? Is this
reasonble?

> I also dislike getting bug reports "I see this problem in [git] revision
> 000000deadbeef00000", which means nothing to me.

It is the revision id, which exactly defines the emacs source code used
for the build. bzr has something like that, but time ago the people here
decided that knowing that information is not really useful, so just
ignore it.

It is funny to see Lars complaining about people reporting bugs from
builds which are a few weeks old, while the Emacs developer community is
happy with the output of (version), which is anything but accurate as it
depends on when the binary was built, not on when the sources were
updated. :-/

> But now cue people moaning about how they don't like bzr and simply must
> use git because of [awesome feature].

For me it is not so much a matter of awesome features but of convenience
given my setup, so I'm happy that some people provide git
mirrors. Though I would appreciate too if they were
regularly/automatically updated, or at least some clear instructions on
how to update a local git mirror with the contents of the Savannah bzr
repo.

Re: Git mirrors

[Lars Magne Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> So you expect from users to fetch and build the very latest sources
> before sending a bug report? 

If they say that they're using a brand-new checked out version -- yes.
Then it turns out that it's from a git mirror that's two weeks old.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Git mirrors

[Juanma Barranquero]

On Fri, Oct 7, 2011 at 00:30, Óscar Fuentes <ofv@wanadoo.es> wrote:

> bzr has something like that, but time ago the people here
> decided that knowing that information is not really useful, so just
> ignore it.

In some other universe, perhaps. In this one, the discussion was not
about where bzr ids are useful, but whether they are so convenient to
use that they should be routinely used when referring to trunk's
revisions in commit logs and ChangeLogs. They are not. Chalk that one
to Bazaar developers insisting on using the e-mail and date as the
*head* of the id, instead of some fast-varying value like a sha-1
digest.

    Juanma

Re: Git mirrors

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Oct 7, 2011 at 00:30, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> bzr has something like that, but time ago the people here
>> decided that knowing that information is not really useful, so just
>> ignore it.
>
> In some other universe, perhaps.

So let's make use of the next wormhole, then.

Some stuff, if you have time to skim over unrelated posts:

http://search.gmane.org/?query=bzr+revision+id+version&group=gmane.emacs.devel

If you are too impatient, peek through this for a quick taste of that
strange universe:

http://article.gmane.org/gmane.emacs.devel/129532

> In this one, the discussion was not
> about where bzr ids are useful, but whether they are so convenient to
> use that they should be routinely used when referring to trunk's
> revisions in commit logs and ChangeLogs. They are not. Chalk that one
> to Bazaar developers insisting on using the e-mail and date as the
> *head* of the id, instead of some fast-varying value like a sha-1
> digest.

Well, they thought that a bare series of hex digits are too intimidating
and put something familiar in front of the hash. Unfortunate, yes.

Re: Git mirrors

[Glenn Morris]

My point was that some revision id from some guy's git repo is no use to
me, not that full revision ids are no use. Please let's not start this
again.

Re: Git mirrors

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> mirrors up-to-date.  Is it so impossible to set up an automatic bzr->git
> gateway?  One that polls and pushes, say, every ten minutes?

Trying to be constructive about this, this would be helpful, but
presumably a fully automatic sync is not possible, or someone would have
done it by now.

If someone can do it, please work to get it done on Savannah so that we
never have to have this discussion again.

Re: Git mirrors

[John Wiegley]

>>>>> Glenn Morris <rgm@gnu.org> writes:

> Trying to be constructive about this, this would be helpful, but presumably
> a fully automatic sync is not possible, or someone would have done it by
> now.

I have my own fully-automated sync happening here on my own machine, using
git-bzr and bzr-fast-import, so I can't imagine it would be any harder for a
server to do.

> If someone can do it, please work to get it done on Savannah so that we
> never have to have this discussion again.

Give me ssh access and I'll do it.

John

Re: Git mirrors

[Stefan Monnier]

>> Trying to be constructive about this, this would be helpful, but
>> presumably a fully automatic sync is not possible, or someone would
>> have done it by now.
> I have my own fully-automated sync happening here on my own machine, using
> git-bzr and bzr-fast-import, so I can't imagine it would be any harder for a
> server to do.
>> If someone can do it, please work to get it done on Savannah so that we
>> never have to have this discussion again.
> Give me ssh access and I'll do it.

Actually, you have write access to Emacs's repository, so also to its
Git mirror, IIUC.  So you could update your script to push your mirror
to git.sv.gnu.org, et voilà!


        Stefan

Re: Git mirrors

[Ted Zlatanov]

On Thu, 06 Oct 2011 21:38:13 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> Actually, you [John Wiegley] have write access to Emacs's
SM> repository, so also to its Git mirror, IIUC.  So you could update
SM> your script to push your mirror to git.sv.gnu.org, et voilà!

I think it would benefit the GNU Emacs project, the Emacs developers and
maintainers, and the Emacs community as a whole if there was an official
read-only Git mirror of the Emacs repository that was updated with every
Bazaar push.  Not polling, but actually triggered by a push.  And this
sync should be recognized as an important convenience to the Emacs
community, not just an afterthought.  It would not imply an endorsement
of Git over Bazaar, and this can be made explicit in web pages and FSF
statements.

We live in an era where DVCS has become a commodity, so this would let
us treat it as such and concentrate on hacking.

Ted

Re: Git mirrors

[Glenn Morris]

Ted Zlatanov wrote:

> I think it would benefit the GNU Emacs project, the Emacs developers and
> maintainers, and the Emacs community as a whole if there was an official
> read-only Git mirror of the Emacs repository that was updated with every
> Bazaar push.

I just want to make the point that since Bazaar is a GNU project, IMO
this would not benefit the GNU project as a whole. (I'm not saying don't
do it, just making a point.)

Re: Git mirrors

[Ted Zlatanov]

On Fri, 07 Oct 2011 12:37:42 -0400 Glenn Morris <rgm@gnu.org> wrote: 

GM> Ted Zlatanov wrote:
>> I think it would benefit the GNU Emacs project, the Emacs developers and
>> maintainers, and the Emacs community as a whole if there was an official
>> read-only Git mirror of the Emacs repository that was updated with every
>> Bazaar push.

GM> I just want to make the point that since Bazaar is a GNU project, IMO
GM> this would not benefit the GNU project as a whole. (I'm not saying don't
GM> do it, just making a point.)

I have seen many projects (including Emacs) that provide tarballs as a
convenience to users, even though they use something else as their VCS.
So to me, this is just an improved tarball with the commit history.  It
happens to be in the Git format and thus many nice tools can use it and
synchronization is easy.  But it's explicitly no better than a tarball
for the purpose of committing changes back, which is the important
message IMO.  If there was another DVCS format that people want as much
as they have asked for Git, then provide it too.

Many open-source and free projects have Subversion-to-Git and x-to-CVS
bridges with the same idea, to make checkouts easier without endorsing
the delivery mechanism.  I don't think it's disingenuous to do this.

Ted

Re: Git mirrors

[Richard Stallman]

    > I think it would benefit the GNU Emacs project, the Emacs developers and
    > maintainers, and the Emacs community as a whole if there was an official
    > read-only Git mirror of the Emacs repository that was updated with every
    > Bazaar push.

    I just want to make the point that since Bazaar is a GNU project, IMO
    this would not benefit the GNU project as a whole. (I'm not saying don't
    do it, just making a point.)

That's my response too.


-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Git mirrors

[Ted Zlatanov]

On Sat, 08 Oct 2011 04:50:07 -0400 Richard Stallman <rms@gnu.org> wrote: 

>> I think it would benefit the GNU Emacs project, the Emacs developers and
>> maintainers, and the Emacs community as a whole if there was an official
>> read-only Git mirror of the Emacs repository that was updated with every
>> Bazaar push.

RS>     I just want to make the point that since Bazaar is a GNU project, IMO
RS>     this would not benefit the GNU project as a whole. (I'm not saying don't
RS>     do it, just making a point.)

RS> That's my response too.

Are you simply ignoring Glenn's last sentence?

Why does Savannah offer Git hosting if you feel even providing a
read-only Git mirror harms the GNU project?

Is Emacs a tool or a weapon?

Ted

Re: Git mirrors

[Óscar Fuentes]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Sat, 08 Oct 2011 04:50:07 -0400 Richard Stallman <rms@gnu.org> wrote: 
>
>>> I think it would benefit the GNU Emacs project, the Emacs developers and
>>> maintainers, and the Emacs community as a whole if there was an official
>>> read-only Git mirror of the Emacs repository that was updated with every
>>> Bazaar push.
>
> RS>     I just want to make the point that since Bazaar is a GNU project, IMO
> RS>     this would not benefit the GNU project as a whole. (I'm not saying don't
> RS>     do it, just making a point.)
>
> RS> That's my response too.
>
> Are you simply ignoring Glenn's last sentence?
>
> Why does Savannah offer Git hosting if you feel even providing a
> read-only Git mirror harms the GNU project?
>
> Is Emacs a tool or a weapon?

I was restraining myself from making this question since long time ago:
is GNU a competing project against other *Free* projects? To the point
of not only promoting a technically inferior package (i.e. bzr) but
trying to inconvenience those who opted by a successful, widely used,
*Free*, non-GNU package? If the answer is yes, how does it helps the
Free Software cause?

This is not a stab on bzr. I'm just bewildered by the attitude of GNU
(which, AFAIK, is a means to promote Free Software, not an end on
itself) towards other Free projects.

Feel free to follow up this privately.

Re: Git mirrors

[Juanma Barranquero]

On Tue, Oct 11, 2011 at 00:52, Óscar Fuentes <ofv@wanadoo.es> wrote:

> promoting a technically inferior package (i.e. bzr)

git's supposed technical advantage over bzr is a matter of discussion.

What cannot be denied, however, is that git has a *lot* more fanboys.

    Juanma

Re: Git mirrors

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

>> promoting a technically inferior package (i.e. bzr)
>
> git's supposed technical advantage over bzr is a matter of discussion.
>
> What cannot be denied, however, is that git has a *lot* more fanboys.

Maybe it has more fanboys because it has more users? And (ignoring your
trap and turning to a constructive stance) it seems logical to easy
things for those who wish to contribute to the project using whatever
Free tools, while the GNU vs The Rest of the World position just stirs
hostility everywhere, including on other Free Software developers. At
this point, if I were a Git or Mercurial developer I wouldn't be full of
sympathy towards GNU (and, by extension, the FSF) seeing how my tool is
deemed by prominent members of the FSF.

Re: Git mirrors

[Juanma Barranquero]

On Tue, Oct 11, 2011 at 03:12, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Maybe it has more fanboys because it has more users?

There's no necessary correlation between fanboys' numbers and user base.

> And (ignoring your trap and turning to a constructive stance)

No trap. Just bored of how many discussions in emacs-devel turn into
another "git is better than bzr" tirade.

    Juanma

Re: Git mirrors

[Miles Bader]

Juanma Barranquero <lekktu@gmail.com> writes:
>> promoting a technically inferior package (i.e. bzr)
>
> git's supposed technical advantage over bzr is a matter of discussion.

Perhaps, but that's not actually so important.  It's clear that git is
technically very good, that it's seen much wider adoption than any of
its competitors, and that it has the bulk of the mindshare in the
"distributed source control" arena.

Given this situation, a competing system is going to have a very hard
time gaining any ground (and will probably slowly lose ground) unless
it's _significantly_ better than git -- and so far, competing systems
(bzr, hg, etc) are at best roughly on par.

[Doesn't mean it won't happen of course, just that the odds are a bit
long.]

> What cannot be denied, however, is that git has a *lot* more fanboys.

Tsk, tsk, now _that's_ flamebait... 

[... and in fact, the opposite is probably true.  Every system starts
out being used by a core of enthusiasts, but git's much farther
towards being over that hump than competing systems like bzr or hg.
Although git's still strongest amongst "technical types", it's seen
huge adoption in many sectors (including stodgy corporate types etc).
Bzr by comparison is still pretty much a niche system kept alive by
the faithful.]

-miles

-- 
Infancy, n. The period of our lives when, according to Wordsworth, 'Heaven
lies about us.' The world begins lying about us pretty soon afterward.

Re: Git mirrors

[Juanma Barranquero]

On Tue, Oct 11, 2011 at 03:39, Miles Bader <miles@gnu.org> wrote:

> Juanma Barranquero <lekktu@gmail.com> writes:
>>> promoting a technically inferior package (i.e. bzr)
>>
>> git's supposed technical advantage over bzr is a matter of discussion.
>
> Perhaps, but that's not actually so important.  It's clear that git is
> technically very good, that it's seen much wider adoption than any of
> its competitors, and that it has the bulk of the mindshare in the
> "distributed source control" arena.

Perhaps, but I'm specifically countering Óscar's affirmation that bzr
is a "technically inferior package". Sociopolitics of git usage is an
interesting topic for another list, IMO.

> Tsk, tsk, now _that's_ flamebait...

Not at all.

    Juanma

Re: Git mirrors

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

>>> git's supposed technical advantage over bzr is a matter of discussion.
>>
>> Perhaps, but that's not actually so important.  It's clear that git is
>> technically very good, that it's seen much wider adoption than any of
>> its competitors, and that it has the bulk of the mindshare in the
>> "distributed source control" arena.
>
> Perhaps, but I'm specifically countering Óscar's affirmation that bzr
> is a "technically inferior package".

Once upon a time Emacs decided to use a DVCS. Mercurial and Git were the
obvious choices. But... lo! Emacs chose a system that, at the time, was
unable to cope with the volume requirements of the project and had to
wait for more than a year until it was barely usable. Now, go and say to
any Git or Mercurial developer that bzr wasn't a technically inferior
choice.

The decision on Bzr was political, not technical, and now objections are
made to adding support for other Free tools as a service to those
contributors that consider them more convenient. What I'm saying is that
that does not send a friendly signal to other Free Software projects and
representing GNU as an unfriendly competitor of other Free tools harms
the cause of Free Software.

[snip]

Re: Git mirrors

[Juanma Barranquero]

On Tue, Oct 11, 2011 at 04:12, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Now, go and say to
> any Git or Mercurial developer that bzr wasn't a technically inferior
> choice.

Are we disagreeing on the meaning of "was[n't]" vs. "is"?

> The decision on Bzr was political, not technical

Believe it or not, and to my *great* chagrin, I was quoted in the
Linux Weekly News saying that (I supported git over bzr back then):

http://lwn.net/Articles/272853/

"Juanma Barranquero sums up his (and others') objections:

What I'm trying to say is: I won't discuss which dVCS we choose
(unless it makes Windows development a PITA). But I agree with Jeremy
Maitin-Shepard that the cause of free software is strengthened by us
selecting among the free alternatives the one that best serves our
technical, not political, needs."

(Being a Windows guy through-and-through, I haven't yet recovered from
the shame of being quoted in a Linux magazine...)

But that was then. Bazaar now is quite a different beast, and
apparently the next major release will natively support colocated
branches and then everything I like from git will be in Bazaar.

    Juanma

Re: Git mirrors

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

>> Now, go and say to
>> any Git or Mercurial developer that bzr wasn't a technically inferior
>> choice.
>
> Are we disagreeing on the meaning of "was[n't]" vs. "is"?

On Tue, Oct 11, 2011 at 00:52, Óscar Fuentes <ofv@wanadoo.es> wrote:

> promoting a technically inferior package (i.e. bzr)

There is no "is" there.

>> The decision on Bzr was political, not technical
>
> Believe it or not, and to my *great* chagrin, I was quoted in the
> Linux Weekly News saying that (I supported git over bzr back then):
>
> http://lwn.net/Articles/272853/
>
> "Juanma Barranquero sums up his (and others') objections:
>
> What I'm trying to say is: I won't discuss which dVCS we choose
> (unless it makes Windows development a PITA). But I agree with Jeremy
> Maitin-Shepard that the cause of free software is strengthened by us
> selecting among the free alternatives the one that best serves our
> technical, not political, needs."

So we are discussing while in full agreement. Typical of emacs-devel.

> (Being a Windows guy through-and-through, I haven't yet recovered from
> the shame of being quoted in a Linux magazine...)

A shame? You are a Windows fanboy, aren't you? :-)

> But that was then. Bazaar now is quite a different beast, and
> apparently the next major release will natively support colocated
> branches and then everything I like from git will be in Bazaar.

There were two factors that made me switch to git from bzr: colocated
branches and Emacs support. I'm glad to hear that the first is being
fully addressed (hope it is done right!) But, AFAIK, there is no Emacs
interface to bzr that can do for it what PCL-CVS did for CVS or psvn for
Subversion. Generic interfaces usually fall short of exploiting the
strong points of the tool and I'm afraid that VC is hardly fixable on
this respect (although it is an essential complement for magit in my
case.)

I won't consider going back to bzr even if it acquired a good Emacs
interface but I'm not trying to convince anyone to switch to git
either. I just want to make sense of the FSF politics about GNU vs
non-GNU Free Software (honest!).

Re: Git mirrors

[Juanma Barranquero]

On Tue, Oct 11, 2011 at 05:07, Óscar Fuentes <ofv@wanadoo.es> wrote:

> There is no "is" there.

Oh, yes: "[...] is GNU a competing project against other *Free*
projects? To the point
of not only promoting a technically inferior package (i.e. bzr)
[...]". Clearly you were speaking about now, not then.

> A shame? You are a Windows fanboy, aren't you? :-)

Not really. I'm a VMS fanboy living in a Windows world. I have no
emotional attachment to Windows, it's just that I cannot tolerate
GNU/Linux; it gets in my nerves. I'm still waiting for a OS I can
really like.

> I just want to make sense of the FSF politics about GNU vs
> non-GNU Free Software (honest!).

Fair enough, but the points have already been made many times before.

    Juanma

Re: Git mirrors

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Tue, Oct 11, 2011 at 05:07, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> There is no "is" there.
>
> Oh, yes: "[...] is GNU a competing project against other *Free*
> projects? To the point
> of not only promoting a technically inferior package (i.e. bzr)
> [...]". Clearly you were speaking about now, not then.

The "is" refers to GNU and specifically to the GNU policy, not to
"promoting ... bzr".

I concede that I consider bzr an inferior choice, technically-wise
(mostly due to design principles.) That is my opinion and maybe pervaded
into the context or you got it from previous messages, but what is
indisputable is that bzr was not ready for the task at the time the
decission was made and the only (and definitive) "advantage" it had over
the competitors was the GNU label.

[snip]

Re: Git mirrors

[Juanma Barranquero]

On Tue, Oct 11, 2011 at 05:45, Óscar Fuentes <ofv@wanadoo.es> wrote:

> The "is" refers to GNU and specifically to the GNU policy, not to
> "promoting ... bzr".

I don't see how the above can be read other than "is GNU a competing
project, to the point of not only promoting a technically inferior
package", etc.

> but what is
> indisputable is that bzr was not ready for the task at the time the
> decission was made

Yes. Was. I already said I agreed at the time.

But this is now, and bzr is ready for the task, and discussing again
what could have been is pointless IMO.

    Juanma

Re: Git mirrors

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 11 Oct 2011 04:12:17 +0200
> Cc: emacs-devel@gnu.org, Miles Bader <miles@gnu.org>
> 
> The decision on Bzr was political, not technical

Yes, it was.  So was the decision to develop GNU Emacs, GCC, and the
whole GNU Project.  And your point is?

> and now objections are made to adding support for other Free tools
> as a service to those contributors that consider them more
> convenient.

No, there are no objections to that.  You (or anyone else) are free to
set out to make that happen, whether on Savannah or elsewhere.

Objections _are_ made to force the Emacs project to do this work for
you, when in fact the Emacs project already provides a reasonable
solution for distributed development and contribution to the project.

Let me turn the table and ask you: are you aware of any significant
number of projects that use git and provide a bzr gateway for those
who want that?  I have yet to see such a project.  And I fully
understand the maintainers of those projects: they have selected a
tool which is a reasonably good one, so people who want to contribute
should use it, or find their own ways of coping.  I do the latter (in
Gawk and in GDB): I use the bzr-git plugin, although it sometimes
makes bzr much slower.  But that's _my_ pain, so _I_ take the
responsibility for applying any painkillers I need.

Why should you expect the Emacs project to behave differently from any
other Free Software project?  If someone have an itch to scratch, that
someone gets to fix it -- unless she succeeds to convince the head
maintainers that the itch is serious enough to be scratched by the
project.  It should be quite clear now, both from what some of the
maintainers wrote and from the silence of others, that this thread
failed to convince them, as did in fact past threads of the same
nature.  So that leaves people who cannot live without git with the
obvious choice -- make it happen, or stop complaining once every few
months.

> What I'm saying is that that does not send a friendly signal to
> other Free Software projects and representing GNU as an unfriendly
> competitor of other Free tools harms the cause of Free Software.

I fail to see how this interpretation can be gleaned from what's been
said here.  Projects that use git as their VCS are not being accused
of being "unfriendly competitors" to the GNU Project, and I, for one,
don't think they are.  So what you say is simply unfair.  I hope
fairness is still a virtue around here.

Re: Git mirrors

[Eli Zaretskii]

> Date: Tue, 11 Oct 2011 03:17:38 -0400
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: lekktu@gmail.com, miles@gnu.org, emacs-devel@gnu.org
> 
> You (or anyone else) are free to set out to make that happen,
> whether on Savannah or elsewhere.

I forgot that Savannah already provides such a mirror.  So I guess
what you need to do is make it update more frequently, and then
(hopefully) we will be free of these endless flame-discuss threads.

Re: Git mirrors

[Ted Zlatanov]

On Tue, 11 Oct 2011 04:14:08 -0400 Eli Zaretskii <eliz@gnu.org> wrote: 

>> Date: Tue, 11 Oct 2011 03:17:38 -0400
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: lekktu@gmail.com, miles@gnu.org, emacs-devel@gnu.org
>> 
>> You (or anyone else) are free to set out to make that happen,
>> whether on Savannah or elsewhere.

EZ> I forgot that Savannah already provides such a mirror.  So I guess
EZ> what you need to do is make it update more frequently, and then
EZ> (hopefully) we will be free of these endless flame-discuss threads.

Not more frequently, but on every commit, so it's *reliable*.

And make it official so we don't have 50 unofficial ones.

Ted

Re: Git mirrors

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Tue, 11 Oct 2011 08:19:08 -0500
> 
> EZ> I forgot that Savannah already provides such a mirror.  So I guess
> EZ> what you need to do is make it update more frequently, and then
> EZ> (hopefully) we will be free of these endless flame-discuss threads.
> 
> Not more frequently, but on every commit, so it's *reliable*.
> 
> And make it official so we don't have 50 unofficial ones.

It is as official as it gets: I saw it on Savannah pages for the Emacs
project.

Re: Git mirrors

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Why should you expect the Emacs project to behave differently from any
 > other Free Software project?

Because most of the projects in the class you have mentioned produce
free *software*, but their political principles are those of the open
source movement.  Emacs is different because it *is* a Free Software
project.  One could argue that Emacs should advocate the use of the
strongest possible "team" of free software tools, rather than being
biased to the use of GNU-labeled tools.  After all, the project has no
problem labelling other non-GNU tools (TeX, perl, X11) as "part of the
GNU System".  But choosing tools on technical capability is clearly
not the policy of the GNU Project, so the point is moot.

 > I fail to see how this interpretation can be gleaned from what's been
 > said here.  Projects that use git as their VCS are not being accused
 > of being "unfriendly competitors" to the GNU Project, and I, for one,
 > don't think they are.  So what you say is simply unfair.  I hope
 > fairness is still a virtue around here.

Promoting an unusable tool merely because it had the GNU label is most
definitely unfriendly competition.  Óscar's description is contentious
but not unfair in this particular case.  

Re: Git mirrors

[Juanma Barranquero]

On Tue, Oct 11, 2011 at 11:33, Stephen J. Turnbull
<turnbull@sk.tsukuba.ac.jp> wrote:

> Promoting an unusable tool merely because it had the GNU label is most
> definitely unfriendly competition.

Assuming that by "unusable tool" you refer to the past, and even if it
is not accurate (it was lacking, but hardly unusable, or we would not
have been able to use it), well... which competition? Though I
disagreed at the time, chosing a tool is not a race, but a decision,
political as much as anything else. It seems logical to chose the one
you favor, and then try to make it better. That git or mercurial or
darcs or any other tool were available and free does not change the
fact that Bazaar was, nominally at least, *the* GNU dVCS of choice.

I think the above makes clear that I don't agree with your comment:
"One could argue that Emacs should advocate the use of the strongest
possible "team" of free software tools, rather than being biased to
the use of GNU-labeled tools." That would be technically sound,
politically less so.

    Juanma

Re: Git mirrors

[Stephen J. Turnbull]

Juanma Barranquero writes:
 > On Tue, Oct 11, 2011 at 11:33, Stephen J. Turnbull
 > <turnbull@sk.tsukuba.ac.jp> wrote:
 > 
 > > Promoting an unusable tool merely because it had the GNU label is most
 > > definitely unfriendly competition.
 > 
 > Assuming that by "unusable tool" you refer to the past, and even if it
 > is not accurate (it was lacking, but hardly unusable, or we would not
 > have been able to use it),

The politically committed did use it.  Many others refused.  Some
stopped contributing, others used the git or Arch mirrors.  For quite
some time, despite the existence of the GNU Savannah, the repo of
choice was hosted at Launchpad.

 > well... which competition?

Excuse me?  The obvious competition: Subversion, git, Mercurial.  The
main technical advantage of Bazaar was allowing the technological
reactionaries to continue using a centralized system.  Subversion
would have served that purpose, and is well-supported by Savannah
AFAIK.  git was and is a much better choice for fostering the "share
my Emacs hacks" ethos that has always been a part of this community,
but would have required substantial effort on the part of the more
conservative members of the community.  Mercurial is somewhere in the
middle, and defintely not as good as Bazaar at supporting centralized
habits, but I have never seen a Mercurial hosting service with the
kind of performance problems that intermittently crop up with Bazaar
even today, let alone the systematic performance problems of the bzr
at the time the decision was made.  Nor have I seen any project have
really severe issues transitioning from a CVS or Subversion repo to a
Mercurial repo with a centralized workflow.

All of the above are indisputably free software.

 > Though I disagreed at the time, chosing a tool is not a race, but a
 > decision, political as much as anything else. It seems logical to
 > chose the one you favor, and then try to make it better.

Richard made the decision.  I don't see Richard making any
contributions to Bazaar at all.  I see Eli and Stefan reporting bugs,
which is indeed a contribution, but hardly *making* it better.  Emacs
is always waiting on Bazaar, waiting on Savannah, waiting, waiting,
waiting.  The decision was made, and as I replied to Ted Z, this is
GNU policy.  However, I don't see a lot of follow-through in the
direction you indicate.  Am I missing something?

 > That git or mercurial or darcs or any other tool were available and
 > free does not change the fact that Bazaar was, nominally at least,
 > *the* GNU dVCS of choice.

Once again, the existence of groff doesn't stop GNU from using TeX.
The existence of bash, gawk, and GNU sed doesn't stop GNU from using
perl.  And so on.

 > I think the above makes clear that I don't agree with your comment:
 > "One could argue that Emacs should advocate the use of the strongest
 > possible "team" of free software tools, rather than being biased to
 > the use of GNU-labeled tools." That would be technically sound,
 > politically less so.

If by "politically sound" you mean fanboyism, sure.  If by
"politically sound" you mean "organizing a consensus of the members of
the GNU project to cooperate in some endeavor at the expense of their
own immediate, local interests", it is indeed arguable that sometimes
a GNU project can be left to its own devices so that other projects
can take advantage of the best available tools.

But as I also said in my message, the argument is over, the decision
is made.  It is *not* "fanboyism" to abide by the decision until it
becomes clear that the decision should be rethought.  I disagree with
the decision, but I don't see a strong argument for rethinking it.
The arguments pro and con haven't changed much in the last 30 years,
and it's clear that most members of the Emacs community are perfectly
happy with "abiding by the decision".

I just object to the way Óscar (inter alia) is being shouted down.  He
has a point.  It would be reasonable to point to the consensus and
say, "That's off-topic."  But he's not being unfair.

Re: Git mirrors

[Juanma Barranquero]

On Wed, Oct 12, 2011 at 06:31, Stephen J. Turnbull
<turnbull@sk.tsukuba.ac.jp> wrote:

> The politically committed did use it. Many others refused.

Many others did use it, even though they were not "politically
committed". I switched to using it, and politics wasn't involved. I
just wanted to hack Emacs. Apparently, for some people distaste of the
tool, or the politics, was stronger than the desire to continue
helping develop Emacs.

> For quite
> some time, despite the existence of the GNU Savannah, the repo of
> choice was hosted at Launchpad.

Yes, there were some rough times at first, and the official repo took
a time to be set up in the best possible way. And even so, using it
was perfectly viable and not half as bad as some wanted to believe.

>  > well... which competition?
>
> Excuse me?  The obvious competition: Subversion, git, Mercurial.

I didn't make myself clear. I didn't mean that there were no technical
alternatives. What I meant is why suppose that selecting the tool was
a competition? It wasn't. There's no written law that says that
switching tools *has* to be a competition. The Emacs project has a
political dimension that GNU Pascal has not, for example.

> git was and is a much better choice for fostering the "share
> my Emacs hacks" ethos that has always been a part of this community,
> but would have required substantial effort on the part of the more
> conservative members of the community.

Sorry, but git is not so evidently superior than disliking it is being
conservative. Suggesting so borders on ad hominem.

> Richard made the decision.  I don't see Richard making any
> contributions to Bazaar at all.  I see Eli and Stefan reporting bugs,
> which is indeed a contribution, but hardly *making* it better.  Emacs
> is always waiting on Bazaar, waiting on Savannah, waiting, waiting,
> waiting.

Please. "Making it better" does not mean hacking Bazaar yourself. The
simple fact that such an important project as Emacs switched to bazaar
certainly did pressure the Bazaar developers to make a lot of
improvements (helped, no doubt, by Eli's many bug reports ;-)

As for waiting, waiting, waiting... The truth is that we waited much
more for the Savannah people to act that for the Bazaar crowd to fix
bugs.

> The decision was made, and as I replied to Ted Z, this is
> GNU policy.  However, I don't see a lot of follow-through in the
> direction you indicate.  Am I missing something?

If you mean that Bazaar is not a lot better now that two or three
years ago, I don't know what to say.

> Once again, the existence of groff doesn't stop GNU from using TeX.
> The existence of bash, gawk, and GNU sed doesn't stop GNU from using
> perl.  And so on.

And Savannah offers git access, etc. It's not like git is forbidden in
GNU projects.

> I just object to the way Óscar (inter alia) is being shouted down.

Óscar is using the past to complain about the present. And he's
refusing to use Bazaar. His prerogative, but is not unlike complaining
why Emacs is written in C and not C++. That's just not the tool that
Emacs use. Please, do adapt.

    Juanma

Re: Git mirrors

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

[snip]

>> I just object to the way Óscar (inter alia) is being shouted down.
>
> Óscar is using the past to complain about the present.

The past is "choosing bzr over other Free alternatives was politicaly
motivated regardless of technical merit; the interests of GNU prevailed,
users were dismissed."

The present is "providing a convenient git mirror is considered not good
for GNU; once again, GNU is considered more important than users."

I always thought that Free Software is about the user, always the
user. But once you begin privileging some packages simply because they
abide to GNU, and viewing others as "not beneficial" because they don't,
irrespectively of its merit, then GNU starts looking as a menacing
entity, something dangerous that pretends to roll over your beloved
creations just because that's good for GNU's self-interest.

> And he's refusing to use Bazaar.

Where I said so?

Since some time ago, this discussion have entered strawman mode.

> His prerogative, but is not unlike complaining
> why Emacs is written in C and not C++. That's just not the tool that
> Emacs use. Please, do adapt.

It is the other way around: the infrastructure must adapt to the needs
of users, whenever there are enough technical and human resources. If
some Emacs hackers feel more at home with
git/mercurial/whatever-other-Free-tool, why not simply provide it? How
could that be "not good" for GNU, the spearhead of Free Software? The
"do adapt" means, exactly, "down your throat!". There is no need for
that, other than political reasons. Those are damaging the user and
sending an unfriendly message to other Free projects.

Re: Git mirrors

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 12 Oct 2011 15:31:03 +0200
> Cc: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>, emacs-devel@gnu.org
> 
> The past is "choosing bzr over other Free alternatives was politicaly
> motivated regardless of technical merit; the interests of GNU prevailed,
> users were dismissed."
> 
> The present is "providing a convenient git mirror is considered not good
> for GNU; once again, GNU is considered more important than users."
> 
> I always thought that Free Software is about the user, always the
> user. But once you begin privileging some packages simply because they
> abide to GNU, and viewing others as "not beneficial" because they don't,
> irrespectively of its merit, then GNU starts looking as a menacing
> entity, something dangerous that pretends to roll over your beloved
> creations just because that's good for GNU's self-interest.

I disagree with this interpretation, but I'm sure Richard will explain
things better than I ever could.

> If some Emacs hackers feel more at home with
> git/mercurial/whatever-other-Free-tool, why not simply provide it?

Because it takes the effort from other useful development tasks.  And
because providing every possible tool, just because someone feels more
at home with it, when reasonable alternatives exist, is not the norm
in Free Software projects.  What is not required from projects that
use git should not be required from projects that use bzr.

Re: Git mirrors

[Richard Riley]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Wed, 12 Oct 2011 15:31:03 +0200
>> Cc: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>, emacs-devel@gnu.org
>> 
>> The past is "choosing bzr over other Free alternatives was politicaly
>> motivated regardless of technical merit; the interests of GNU prevailed,
>> users were dismissed."
>> 
>> The present is "providing a convenient git mirror is considered not good
>> for GNU; once again, GNU is considered more important than users."
>> 
>> I always thought that Free Software is about the user, always the
>> user. But once you begin privileging some packages simply because they
>> abide to GNU, and viewing others as "not beneficial" because they don't,
>> irrespectively of its merit, then GNU starts looking as a menacing
>> entity, something dangerous that pretends to roll over your beloved
>> creations just because that's good for GNU's self-interest.
>
> I disagree with this interpretation, but I'm sure Richard will explain
> things better than I ever could.
>
>> If some Emacs hackers feel more at home with
>> git/mercurial/whatever-other-Free-tool, why not simply provide it?
>
> Because it takes the effort from other useful development tasks.  

And you dont feel this one off task of setting up the mirror is
worthwhile when compared to the possibly thousands of people familiar
with git that are not familiar with the vastly slower and more
cumbersome bzr having to learn bzr and come up across the endless
freezes and slow transfer rates that have prompted people to request a
working git mirror in the first place? Strange. I would think anyone
involved with emacs would want to make the trunk available to more
people.

Re: Git mirrors

[Eli Zaretskii]

> From: Richard Riley <rileyrg@googlemail.com>
> Date: Wed, 12 Oct 2011 17:12:55 +0200
> 
> And you dont feel this one off task of setting up the mirror is
> worthwhile when compared to the possibly thousands of people familiar
> with git that are not familiar with the vastly slower and more
> cumbersome bzr having to learn bzr and come up across the endless
> freezes and slow transfer rates that have prompted people to request a
> working git mirror in the first place?

Bazaar is not vastly slower nor cumbersome.  It may have been that
long ago (like a year or 2), but that's not true now.  Perhaps you
should try again the latest version.

> Strange. I would think anyone involved with emacs would want to make
> the trunk available to more people.

Its availability with bzr is very reasonable, so I think there's no
significant problems to fix here, for Emacs as a project.

Re: Git mirrors

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

>> If some Emacs hackers feel more at home with
>> git/mercurial/whatever-other-Free-tool, why not simply provide it?
>
> Because it takes the effort from other useful development tasks.

Eli, please don't do selective quoting. This is what I said, which makes
your sentence above irrelevant:

Óscar Fuentes <ofv@wanadoo.es> writes:

> It is the other way around: the infrastructure must adapt to the needs
> of users, whenever there are enough technical and human resources. If
> some Emacs hackers feel more at home with
> git/mercurial/whatever-other-Free-tool, why not simply provide it?

"enough technical and human resources" == we have the machines, the
bandwith and someone is willing to do the job.

> And because providing every possible tool, just because someone feels
> more at home with it, when reasonable alternatives exist, is not the
> norm in Free Software projects.  What is not required from projects
> that use git should not be required from projects that use bzr.

You talk about "required" as if someone were asking for a rule:
"projects who use bzr must provide git mirrors." That's not the case and
you know it.

Why not support as much as possible as long as someone wishes to do the
work? MSDOS anyone, Eli? You want it, you do the work, it keeps you
contributing, and that's good for Emacs. Why it is different with those
who feel more comfortable (and productive!) using a different VC tool?
That means more contributions to Emacs. How could that be "not
beneficial" for GNU?

And if no project who uses git offers bzr too, maybe that's because such
request is never made, because there is just a small group of users who
strongly prefer bzr over git/mercurial, with most projects having none,
and possibly too because offering bzr support is not as straightforward
as offering git, as we are experiencing, or the contrary, creating a bzr
mirror in Launchpad wich updates daily is easy enough. Not because there
is some kind of attitude of git users towards bzr users that should be
corresponded.

Re: Git mirrors

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 12 Oct 2011 17:23:49 +0200
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> > It is the other way around: the infrastructure must adapt to the needs
> > of users, whenever there are enough technical and human resources. If
> > some Emacs hackers feel more at home with
> > git/mercurial/whatever-other-Free-tool, why not simply provide it?
> 
> "enough technical and human resources" == we have the machines, the
> bandwith and someone is willing to do the job.

And those who are willing to do the job just did it.  No one prevented
them from doing so.  What is the problem?

I was answering your "why" question from the POV of Emacs as a
project.  The Emacs project does not need to do this job, IMO.
Motivated volunteers can do it, if they want to, but the demands that
the project invest any significant effort in this is unfair.

> > And because providing every possible tool, just because someone feels
> > more at home with it, when reasonable alternatives exist, is not the
> > norm in Free Software projects.  What is not required from projects
> > that use git should not be required from projects that use bzr.
> 
> You talk about "required" as if someone were asking for a rule:
> "projects who use bzr must provide git mirrors." That's not the case and
> you know it.

It seems to be the rule in this case.  I'm not involved in any other
project whose main VCS is bzr to say more.

> Why not support as much as possible as long as someone wishes to do the
> work? MSDOS anyone, Eli? You want it, you do the work, it keeps you
> contributing, and that's good for Emacs. Why it is different with those
> who feel more comfortable (and productive!) using a different VC tool?

It is different because if I stop maintaining the DOS port, it will
cease to exist.  By contrast, if we don't have a git gateway, Emacs
sources are still accessible and development can continue unimpeded.

> And if no project who uses git offers bzr too, maybe that's because such
> request is never made

Wrong.  I did request it once.  I won't do that again because the
reaction was nowhere as friendly as what you got here asking for git.

> Not because there is some kind of attitude of git users towards bzr
> users that should be corresponded.

Given what I read here, I will have hard time believing in the absence
of "attitude".  But that's me.

Re: Git mirrors

[Jambunathan K]

Oscar

I am having trouble understanding your arguments.

An official git mirror is made available. In none of your mails you seem
to be acknowledging this fact. You are continuing to complain.

Are you lobbying for migrating Emacs development away from Bzr to git?

Jambunathan K.
-- 

Re: Git mirrors

[Vijay Lakshminarayanan]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Juanma Barranquero <lekktu@gmail.com> writes:
>
> [snip]
>
>>> I just object to the way Óscar (inter alia) is being shouted down.
>>
>> Óscar is using the past to complain about the present.
>
> The past is "choosing bzr over other Free alternatives was politicaly
> motivated regardless of technical merit; the interests of GNU prevailed,
> users were dismissed."

I don't get this.  Eli raised the same earlier.  Yes, it was a political
decision.  What's wrong with that?

> The present is "providing a convenient git mirror is considered not good
> for GNU; once again, GNU is considered more important than users."

Once again, I don't understand.  There's a git mirror.  It isn't perfect
but they're working on it.

> I always thought that Free Software is about the user, always the
> user. But once you begin privileging some packages simply because they
> abide to GNU, and viewing others as "not beneficial" because they don't,
> irrespectively of its merit, then GNU starts looking as a menacing
> entity, something dangerous that pretends to roll over your beloved
> creations just because that's good for GNU's self-interest.

Some projects are "not beneficial".  The FSF and GNU Project have stated
goals and aims.  They are political in nature.  When this is the case,
the metrics used to measure merits of one project over another are
different.  It appears to me that you're entirely stuck upon so-called
technical merits (git awesome; bzr sucks) which is an entirely different
debate.

>> His prerogative, but is not unlike complaining
>> why Emacs is written in C and not C++. That's just not the tool that
>> Emacs use. Please, do adapt.
>
> It is the other way around: the infrastructure must adapt to the needs
> of users, whenever there are enough technical and human resources. If
> some Emacs hackers feel more at home with
> git/mercurial/whatever-other-Free-tool, why not simply provide it? How
> could that be "not good" for GNU, the spearhead of Free Software? The
> "do adapt" means, exactly, "down your throat!". There is no need for
> that, other than political reasons. Those are damaging the user and
> sending an unfriendly message to other Free projects.

Emacs and several other GNU projects are the /only/ projects I know
which officially make their sources available in multiple SCMs.  You
could go complain to the developers of, say, OpenJDK or FireFox and
insist that they provide their sources in git/bzr.  I doubt it'll go
anywhere.  Why you expect differently here is again beyond me.

-- 
Cheers
~vijay

Gnus should be more complicated.

Re: Git mirrors

[Óscar Fuentes]

Vijay Lakshminarayanan <laksvij@gmail.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Juanma Barranquero <lekktu@gmail.com> writes:
>>
>> [snip]
>>
>>>> I just object to the way Óscar (inter alia) is being shouted down.
>>>
>>> Óscar is using the past to complain about the present.
>>
>> The past is "choosing bzr over other Free alternatives was politicaly
>> motivated regardless of technical merit; the interests of GNU prevailed,
>> users were dismissed."
>
> I don't get this.  Eli raised the same earlier.  Yes, it was a political
> decision.  What's wrong with that?

For the nth time: I want to know why such policy is considered good for
the Free Software cause (being GNU an instrument of such cause), because
I perceive that such policy creates animosity among the creators of Free
Software and goes against the principle of merit, which is second after
Freedom.

Anything else are strawman arguments introduced by others, who are
reacting on a Paulovian way at the presence of certain keywords :-)

[snip]

> Emacs and several other GNU projects are the /only/ projects I know
> which officially make their sources available in multiple SCMs.

You don't know the projects that I know, then.

To be fair, it is so easy to create and host a git/mercurial/bzr mirror
of a Subversion/git/mercurial project that there is no need for official
support. AFAIK, it is not so easy to create and host a git mirror of a
bzr project, probably because the main hosting sites (github, gitorious,
etc) does not consider bzr relevant enough to care. And now you will
ask: "why don't you ask those hosting sites to add bzr support?" and my
response is: "this subthread is not about that (see above)."

[snip]

Re: Git mirrors

[Vijay Lakshminarayanan]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Vijay Lakshminarayanan <laksvij@gmail.com> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> Juanma Barranquero <lekktu@gmail.com> writes:
>>>
>>> [snip]
>>>
>>>>> I just object to the way Óscar (inter alia) is being shouted down.
>>>>
>>>> Óscar is using the past to complain about the present.
>>>
>>> The past is "choosing bzr over other Free alternatives was politicaly
>>> motivated regardless of technical merit; the interests of GNU prevailed,
>>> users were dismissed."
>>
>> I don't get this.  Eli raised the same earlier.  Yes, it was a political
>> decision.  What's wrong with that?
>
> For the nth time: I want to know why such policy is considered good for
> the Free Software cause (being GNU an instrument of such cause), because
> I perceive that such policy creates animosity among the creators of Free
> Software and goes against the principle of merit, which is second after
> Freedom.

I don't believe that git is technically superior to bzr.  So your
"principle of merit" does not hold here.

> Anything else are strawman arguments introduced by others, who are
> reacting on a Paulovian way at the presence of certain keywords :-)
>
> [snip]
>
>> Emacs and several other GNU projects are the /only/ projects I know
>> which officially make their sources available in multiple SCMs.
>
> You don't know the projects that I know, then.

Very likely.  And if said projects do exist out there in the wild,
asking them to support One More SCM will probably get you nowhere.

> To be fair, it is so easy to create and host a git/mercurial/bzr mirror
> of a Subversion/git/mercurial project that there is no need for official
> support. AFAIK, it is not so easy to create and host a git mirror of a
> bzr project, probably because the main hosting sites (github, gitorious,
> etc) does not consider bzr relevant enough to care. And now you will
> ask: "why don't you ask those hosting sites to add bzr support?" and my
> response is: "this subthread is not about that (see above)."

This seems like more reason to support bzr.  As a GNU project, it takes
higher priority than other Free Software projects out there.

And now that I've said the above, your question, quite justifiably is:
(repeated from above)

> For the nth time: I want to know why such policy is considered good for
> the Free Software cause (being GNU an instrument of such cause), 

The reason to support GNU projects over others is that it is the stated
goal of GNU that all distributed software should be Free and copylefted
by law.  To this end, any software project that shares the same goals
will be supported.

Git, Linux etc., fall under the principle of "Open Source" which is a
pragmatic rather than political movement.  This movement states that
software must be Open Sourced because that's the best way to develop
software in general and that free software is of higher (technical)
quality than proprietary software.  It follows from this that if it can
be proven that software is better developed behind closed doors and
released proprietarily said advocates must drop what they're doing and
release their code proprietarily.  (Before you say otherwise, Adobe
Photoshop is /way/ better than GNU Gimp and Microsoft Word is /way/
better than Libre Office.)

The GNU project makes no such claims.  In their words, free software is
its own good.  Just like free speech implies people can freely make
racist statements, free software implies that there can be free software
out there that does bad things.

Please note that these are /my/ opinions and not those of FSF.  I don't
represent the FSF in any capacity.

-- 
Cheers
~vijay

Gnus should be more complicated.

Re: Git mirrors

[Helmut Eller]

* Vijay Lakshminarayanan [2011-10-12 17:19] writes:

>> For the nth time: I want to know why such policy is considered good for
>> the Free Software cause (being GNU an instrument of such cause), 
>
> The reason to support GNU projects over others is that it is the stated
> goal of GNU that all distributed software should be Free and copylefted
> by law.  To this end, any software project that shares the same goals
> will be supported.
>
> Git, Linux etc., fall under the principle of "Open Source" which is a
> pragmatic rather than political movement. 

If I'm not mistaken, even RMS uses Linux instead of Hurd.  Double
standards?  

Helmut

Re: Git mirrors

[Jambunathan K]

> If I'm not mistaken, even RMS uses Linux instead of Hurd.  Double
> standards?

Wrong list. This doesn't concern Emacs even remotely.

-- 

Re: Git mirrors

[Helmut Eller]

* Jambunathan K [2011-10-12 18:30] writes:

>> If I'm not mistaken, even RMS uses Linux instead of Hurd.  Double
>> standards?
>
> Wrong list. This doesn't concern Emacs even remotely.

GNU policies concerning Emacs are definitely on topic on this list.

Helmut

Re: Git mirrors

[Ted Zlatanov]

On Wed, 12 Oct 2011 20:21:34 +0200 Helmut Eller <eller.helmut@gmail.com> wrote: 

HE> If I'm not mistaken, even RMS uses Linux instead of Hurd.  Double
HE> standards?  

I'll bet he buys clothes, too.  Shameful.

Ted

Re: Git mirrors

[Giuseppe Scrivano]

Vijay Lakshminarayanan <laksvij@gmail.com> writes:

> Git, Linux etc., fall under the principle of "Open Source" which is a
> pragmatic rather than political movement.  This movement states that
> software must be Open Sourced because that's the best way to develop
> software in general and that free software is of higher (technical)
> quality than proprietary software.

so what?  Does it make Git less Free?

Re: Git mirrors

[Burton Samograd]

Giuseppe Scrivano <gscrivano@gnu.org> writes:

> Vijay Lakshminarayanan <laksvij@gmail.com> writes:
>
>> Git, Linux etc., fall under the principle of "Open Source" which is a
>> pragmatic rather than political movement.  This movement states that
>> software must be Open Sourced because that's the best way to develop
>> software in general and that free software is of higher (technical)
>> quality than proprietary software.
>
> so what?  Does it make Git less Free?

Git is licensed under GPL V2, so I can't see how git is any less free
than bzr.  What does it take to make a project an 'offical GNU project'?
Why could git not be an 'offical GNU project'?

--
Burton Samograd

Re: Git mirrors

[Vijay Lakshminarayanan]

Burton Samograd <bsamograd@interalia.com> writes:

> Giuseppe Scrivano <gscrivano@gnu.org> writes:
>
>> Vijay Lakshminarayanan <laksvij@gmail.com> writes:
>>
>>> Git, Linux etc., fall under the principle of "Open Source" which is a
>>> pragmatic rather than political movement.  This movement states that
>>> software must be Open Sourced because that's the best way to develop
>>> software in general and that free software is of higher (technical)
>>> quality than proprietary software.
>>
>> so what?  Does it make Git less Free?
>
> Git is licensed under GPL V2, so I can't see how git is any less free
> than bzr.  What does it take to make a project an 'offical GNU project'?
> Why could git not be an 'offical GNU project'?

And bzr is licensed under GPLv3 which is a freer license than v2.

> --
> Burton Samograd

-- 
Cheers
~vijay

Gnus should be more complicated.

Re: Git mirrors

[Stephen J. Turnbull]

Burton Samograd writes:

 > What does it take to make a project an 'offical GNU project'?

See "What it means for a program to be a GNU package" in
<URL:http://www.gnu.org/help/evaluation.html>

 > Why could git not be an 'offical GNU project'?

In a word, "Linus Torvalds."

More seriously, take a look at the source.  Although it *is* GPLv2, a
grep through the documentation in /usr/share/doc/git-1.7.7 on a Gentoo
system showed exactly one reference to the GPL, which states that the
only license for git is GPLv2.  I don't recall seeing any
copyright/permission headers anywhere in the tree, and no
advertisements for free software or GNU or the FSF.  This is not a
candidate for a GNU package, in fact if I didn't know Linus is too
stiff-necked to pull an Eric A. Young I'd think this was a deliberate
strategy to prevent inclusion of git as a GNU package.

Linus *does* free software, but he is unwilling to pay lip service to
the Free Software Movement just to get the GNU imprimatur on his code,
and pretty obviously he has a very different take on the whole thing
from the Free Software Movement.

Re: Git mirrors

[Burton Samograd]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:
> Linus is too stiff-necked to pull an Eric A. Young

Could you explain this? I do not get the reference.

--
Burton Samograd

Re: Git mirrors

[Stephen J. Turnbull]

Burton Samograd writes:

 > "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:
 > > Linus is too stiff-necked to pull an Eric A. Young
 > 
 > Could you explain this? I do not get the reference.

Eric Young wrote parts of an SSL library used in most free BSD
distributions.  It was (is?) used in OpenSSL and therefore OpenSSH.

His license is a copyleft BSD license.  No joke.  I forget the
wording, but the license requires that if you redistribute the code,
you must use the BSD+EAY license.  This makes it incompatible with all
strong copyleft licenses, in particular the GPL.

I have no knowledge of the background to his action, but it would seem
to be pure spite, as for practical purposes it only affects use of the
SSL library in copylefted programs.

Re: Git mirrors

[Richard Stallman]

    Please note that these are /my/ opinions and not those of FSF.  I don't
    represent the FSF in any capacity.

I think you explained the issues well, for the most part.
But there are actually two separate issues here: free software vs
open source, and GNU vs non-GNU.

Linux illustrates the difference in philosophy between free software
and open source.  Torvalds' version of Linux tries to install many
nonfree programs, and even contains some (the "binary blobs").  Thus,
it isn't all free software.  It isn't even all open source.
 
This is not hypocrisy on Torvalds' part, because his "open source"
philosophy doesn't say that this is wrong.  It is wrong from our point
of view, however.  This is why we maintain Linux Libre.

However, git is a different case.  It is entirely free software, as
far as I know (please correct me if that isn't so).  Thus, we don't
criticize it, and we're not against it.

Git is simply a rival.  We are not against it, but GNU Project
activities ought to promote the GNU package for this job.

-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Git mirrors

[Richard Stallman]

Everything we do here is for political reasons, and it always was.

    I always thought that Free Software is about the user, always the
    user.

The free software movement campaigns for users' freedom.
So you could say it is "about the users' freedom".

It would be an error to simplify that into "about the user", because
that could be miscontrued as including other benefits even at the
expense of freedom.  For instance, some users like using Skype;
someone might say the GNU system would be "better for users" if it
included Skype and made them happy.  If we adopted the motto that
"free software is about the user", we would be at a loss for how to
argue against that proposal.

So it is not our goal to give users what they happen to want.
Our goal is to give them freedom.

Users who don't want freedom can, of course, disregard it.  Many do.
But if they say, "I don't want freedom, I want Skype", we disregard
them.

Git isn't proprietary, as Skype is.  We're not against git.  But we
are trying to promote Bzr because it is part of GNU.

The most basic way to promote another free program is to use it and
recommend it.  So that's what we do.  Using a free program helps it
get better, and Bzr has got better.

-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Git mirrors

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

> Everything we do here is for political reasons, and it always was.
>
>     I always thought that Free Software is about the user, always the
>     user.
>
> The free software movement campaigns for users' freedom.
> So you could say it is "about the users' freedom".

[snip]

> Users who don't want freedom can, of course, disregard it.  Many do.
> But if they say, "I don't want freedom, I want Skype", we disregard
> them.
>
> Git isn't proprietary, as Skype is.  We're not against git.  But we
> are trying to promote Bzr because it is part of GNU.

I think that we agree that the final goal of the Free Software cause is
Free Software prevalence as a result of the understanding by the public
of its implications. GNU is just a means for that end, but it can't be
considered just another project creating Free Software. On terms of
image, GNU is the FSF and the FSF is the cornerstone of the Free
Software cause. So what GNU does has consequences for the Free Software
cause. The following is based on that premise.

How does it help the Free Software cause to privilege projects over
other Free alternatives putting merit aside just because they have the
GNU label sticked on them?

Why is it necessary to proclaim an official GNU Distributed Version
Control System (DVCS)? GNU has the technical goal of creating a Free
Unix-like OS. For that you strategically depend on a kernel, a compiler,
a linker, a shell... but a DVCS? Is it necessary to proclaim the
official GNU Solitaire card game?

Why not choose the most convenient DVCS for Emacs development (that
could be bzr) as long as it is Free, the same way you use the Linux
kernel on GNU Libre instead of Hurd? A kernel is an indispensable
component for an OS, a DVCS is not. You have no problem using Linux
instead of Hurd because the latter is not ready and the first is Free
and does the job. Why was applied a different criteria when Emacs
decided to use a DVCS?

Why is deemed "not beneficial" for GNU to provide convenient access to
source code through other Free non-GNU tools?

Is that policy good for enhancing user's Freedom or is it doing the
opposite? (by promoting software that *could* be inferior to other
options hence increasing the risk of bad image or rejection; by making
harder to access or contribute to Free projects hosted by GNU; by
sending the message to other creators of Free Software that GNU is out
there to aggressively compete with them regardless of merit.)

> The most basic way to promote another free program is to use it and
> recommend it.  So that's what we do.  Using a free program helps it
> get better, and Bzr has got better.

Have you read Karl Fogel's post on this same thread about how choosing
bzr for Emacs actually *damaged* bzr?

Re: Git mirrors

[Juanma Barranquero]

On Fri, Oct 14, 2011 at 01:26, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Why is it necessary to proclaim an official GNU Distributed Version
> Control System (DVCS)? GNU has the technical goal of creating a Free
> Unix-like OS. For that you strategically depend on a kernel, a compiler,
> a linker, a shell... but a DVCS? Is it necessary to proclaim the
> official GNU Solitaire card game?

Are you seriously comparing Solitaire with a VCS? Most software
projects are mainained with the help of a VCS, and if chosing one as
"official", a DVCS seems more sensible than a non-distributed one. If
you can do a meaningful comparison, compare having an "official VCS"
with having an "official building tool", which is surely not
necessay... Oh, wait. There's GNU make.

> (by promoting software that *could* be inferior to other
> options hence increasing the risk of bad image or rejection;

All software could be inferior. Most are, at one point or other of
their lifecycle. CVS was the most techically advanced VCS, once.

> by making
> harder to access or contribute to Free projects hosted by GNU;

I really dislike this argument, because it means that people who wants
to contribute to some free software project will avoid to do so
because it does not use their tool of choice. But, by the same token,
all projects should be written only in the most popular programming
languages (C and Java, likely), and many do, but there are others.
Let's face it, there are about five or so VCS with are mostly relevant
to free software projects (CVS, Subversion, git, Bazaar and
Mercurial), and to contribute you just have to learn a few commands.
If people does not contribute to Emacs because they have to learn less
than ten bzr commands, they weren't likely to contribute in the first
place.

And, by that token, I woudn't tout git, which is IMO the less
user-friendly for a beginner. I'd go so far as to say that using git
would "mak[e] harder to access or contribute to Free projects hosted
by GNU", as compared to bzr (Subversion would still win, as easier to
learn and really well documented, for centralized projects).

> by
> sending the message to other creators of Free Software that GNU is out
> there to aggressively compete with them regardless of merit.)

GNU software is out there to aggressively compete, and win the users,
yes (at least the ones that care about freedom too). "Regardless of
merit" is meaningless, because the users will chose the one which best
fits their needs.

> Have you read Karl Fogel's post on this same thread about how choosing
> bzr for Emacs actually *damaged* bzr?

It's funny that you use Karl's post to support your view, because he says:

> It is *because* I support free software that I wish Emacs would switch
> to Git on Savannah.  Doing so would be better for the cause.
>
> That's no slur on Bazaar.  It's just that Savannah clearly does not have
> have the resources to support many different version control systems
> well -- and as a result, we're not really helping Bazaar anyway.

which is to say that Savannah is doing a better job of supporting git
than Bazaar... That does not seem entirely compatible with the view
that GNU is rejecting git or favoring Bazaar.

As for Karl's comment, I think that the switch to Bazaar hurt that
project PR-wise, yes, and the state of bzr support on Savannah had a
part on it. But another, huge part, was the fact that bazaar was not,
at the time, ready for a big project with a long history, like Emacs.

But that was then. Currently, wanting to hack Emacs and not wanting to
use Bazaar seems a bit childish IMO. Yes, you'd prefer to use git. I
would prefer for Emacs to be written in Ada. I'll have to adapt. Can
you?

    Juanma

Re: Git mirrors

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Oct 14, 2011 at 01:26, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> Why is it necessary to proclaim an official GNU Distributed Version
>> Control System (DVCS)? GNU has the technical goal of creating a Free
>> Unix-like OS. For that you strategically depend on a kernel, a compiler,
>> a linker, a shell... but a DVCS? Is it necessary to proclaim the
>> official GNU Solitaire card game?
>
> Are you seriously comparing Solitaire with a VCS?

Your irony detector is badly broken, Juanma. Call 112 before it is too
late :-)

> Most software
> projects are mainained with the help of a VCS, and if chosing one as
> "official", a DVCS seems more sensible than a non-distributed one. If
> you can do a meaningful comparison, compare having an "official VCS"
> with having an "official building tool", which is surely not
> necessay... Oh, wait. There's GNU make.

The existence of GNU make (or GNU bzr) does not immediately imply that
other tools with similar or overlapping functionality can't be more
appropriate for certain applications. AFAIR GNU is not free of
duplication. Let's suppose that the mercurial guys submit their tool to
GNU. So now what? The "official GNU DVCS" may be not as convenient as
other for certain purposes. (BTW, is there a "official GNU text editor?"
What can be?) Fact is: git, mercurial and bzr are not the same, in the
same sense that two linkers are the same as long as they are drop-ins
for each other. Actually, a DVCS is more similar to a programmer's
editor than to a linker. People don't feel attached to a linker. We all
know what happens with text editors.

>> (by promoting software that *could* be inferior to other
>> options hence increasing the risk of bad image or rejection;
>
> All software could be inferior. Most are, at one point or other of
> their lifecycle. CVS was the most techically advanced VCS, once.

So what? Is it good then to promote a package that is being largely
ignored by the community as if the words "official GNU whatever" were
magical? The developers out there are choosing their tools based on
their own best judgment (let's hope it is a sensible one) but GNU just
advertises a package as if it were the best possible option just because
someone filled some papers. Silly.

>> by making
>> harder to access or contribute to Free projects hosted by GNU;
>
> I really dislike this argument, because it means that people who wants
> to contribute to some free software project will avoid to do so
> because it does not use their tool of choice.

C'mon, Juanma. We are on emacs-devel. When the bug reporting system was
discussed, people threatened with not using the system or stopping their
contribution to Emacs altogether in case the system lacked X or required
Y (an email interface or a webforms interface, to be precise.) The same
thing just happened with the git mirror. And I somehow understand
that. Would you keep contributing your free time to a project if they
required something that makes you feel uncomfortable?

> But, by the same token,
> all projects should be written only in the most popular programming
> languages (C and Java, likely), and many do, but there are others.
> Let's face it, there are about five or so VCS with are mostly relevant
> to free software projects (CVS, Subversion, git, Bazaar and
> Mercurial), and to contribute you just have to learn a few commands.

And install the tool, and re-learn the commands every now and then
because you don't hack on Emacs every day, and cope with glitches
(apparent or real) on a unfamiliar tool, and use interfaces that makes
you cringe, specially when you remember how good are the ones available
next door...

[snip]

>> by
>> sending the message to other creators of Free Software that GNU is out
>> there to aggressively compete with them regardless of merit.)
>
> GNU software is out there to aggressively compete, and win the users,
> yes (at least the ones that care about freedom too). "Regardless of
> merit" is meaningless, because the users will chose the one which best
> fits their needs.

No if the user trusts GNU, and no if GNU promotes only the subset of
Free Software that was incorporated into GNU.

>> Have you read Karl Fogel's post on this same thread about how choosing
>> bzr for Emacs actually *damaged* bzr?
>
> It's funny that you use Karl's post to support your view, because he says:
>
>> It is *because* I support free software that I wish Emacs would switch
>> to Git on Savannah.  Doing so would be better for the cause.
>>
>> That's no slur on Bazaar.  It's just that Savannah clearly does not have
>> have the resources to support many different version control systems
>> well -- and as a result, we're not really helping Bazaar anyway.
>
> which is to say that Savannah is doing a better job of supporting git
> than Bazaar... That does not seem entirely compatible with the view
> that GNU is rejecting git or favoring Bazaar.

Now, we should ask the Savannah admins why bzr has problems while git
works rock-solid.

> As for Karl's comment, I think that the switch to Bazaar hurt that
> project PR-wise, yes, and the state of bzr support on Savannah had a
> part on it. But another, huge part, was the fact that bazaar was not,
> at the time, ready for a big project with a long history, like Emacs.

Precisely, Emacs did not a favor to bzr choosing it when it was not up
to the task. That's the typical consequence of short-sighted politics.

> But that was then. Currently, wanting to hack Emacs and not wanting to
> use Bazaar seems a bit childish IMO. Yes, you'd prefer to use git. I
> would prefer for Emacs to be written in Ada. I'll have to adapt. Can
> you?

I don't have write access nor have any planned contribution that
requires it, so I'm not the most relevant person to ask that
question. The git mirror serves me perfectly. And when I say "perfectly"
I mean "much better than bzr". If GNU decided to pull the plug on the
git mirror I'll be inconvenienced. Just that. Is it necessary?

Re: Git mirrors

[Juanma Barranquero]

On Fri, Oct 14, 2011 at 04:39, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Your irony detector is badly broken, Juanma. Call 112 before it is too
> late :-)

Unnecessary, I think. I can detect the irony in asking for a GNU
Solitaire, but there's no irony in the fact that you're using reductio
ad absurdum to put (d)VCSs in the same package that other trivial
toosl, when VCSs are in the same category that compilers, linkers,
run-time libraries and text editors. That's what I'm answering to.

> The existence of GNU make (or GNU bzr) does not immediately imply that
> other tools with similar or overlapping functionality can't be more
> appropriate for certain applications.

No, but AFAIK, there's no other official GNU build system (I'm talking
now about make and the autotools, of course). Not cmake, scons,
(b)jam, ant...

> Let's suppose that the mercurial guys submit their tool to
> GNU. So now what?

There would likely be two "official GNU DVCS". You're the one talking
about exclusion. The preference of Bazaar over git is *because* git
does not promote the free software ideas. If Linus, or Junio Hamano,
or whomever has the power to do it, were to turn it into an official
GNU package, I bet GNU would not reject it.

> So what? Is it good then to promote a package that is being largely
> ignored by the community as if the words "official GNU whatever" were
> magical?

Is Bazaar largely ignored by the community? Is git's popularity a
consequence of it being "technically superior" (assuming it is, which
I don't believe), even with the worst documentation I've ever had the
displeasure to read, or because it is the brainchild of fan favorite
Linus Torvalds?

> The developers out there are choosing their tools based on
> their own best judgment (let's hope it is a sensible one)

You say that, and then, a few lines afterwards, you argument that the
users are going to use Bazaar because they "trust GNU".

> but GNU just
> advertises a package as if it were the best possible option just because
> someone filled some papers. Silly.

Two comments: 1) it does not advertise it as if it were the "best
possible option", just the recommended one. They also recommend
gNewSense. 2) "best" is a very loaded metric; as the gNewSense example
shows, "more free" counts.

> C'mon, Juanma. We are on emacs-devel. When the bug reporting system was
> discussed, people threatened with not using the system or stopping their
> contribution to Emacs altogether in case the system lacked X or required
> Y (an email interface or a webforms interface, to be precise.)

I think you exagerate a bit. I remember RMS saying that an e-mail
interface was required, because he doesn't use a web browser. As for
the rest, of course people fought for their preferred systems and/or
interfaces, but I don't think we've had many losses because of the
choice made. Trust me, I do not like debbugs a bit, and still here am
I.

> Would you keep contributing your free time to a project if they
> required something that makes you feel uncomfortable?

That's a loaded question. I would *not* contribute to a project that
required something that made me uncomfortable, but few things in a
free software project, other than the use of Java, will make me
umconfortable enough to keep me from contributing, if the project
interests me. Certainly, choice of VCS or build system would not.

> And install the tool, and re-learn the commands every now and then
> because you don't hack on Emacs every day, and cope with glitches
> (apparent or real) on a unfamiliar tool, and use interfaces that makes
> you cringe, specially when you remember how good are the ones available
> next door...

Again, I think you're exaggerating. I reinstall bzr to be up-to-date
because I want, not because I'm forced to, and I haven't needed to
reinstall Subversion or git for a long while. It seems like you're
arguing that anything new is a big challenge that the user cannot
overcome. If so, they also will not be able or willing to dive into
the Emacs innards to fix problems or extend it. And if they happen to
do it anyway, but they find Bazaar so tasteless, they can just make a
diff with their tool of choice and send it as is.

> Now, we should ask the Savannah admins why bzr has problems while git
> works rock-solid.

It wasn't a bzr problem. It was the Savannah hackers, which lacked
resources and took a long time to upgrade the server.

> Precisely, Emacs did not a favor to bzr choosing it when it was not up
> to the task.

This is difficult to know until you try it, and the signals coming
from the Bazaar developers were positive.

> That's the typical consequence of short-sighted politics.

Circular reasoning detected.

> The git mirror serves me perfectly. And when I say "perfectly"
> I mean "much better than bzr".

Do you regularly use bzr, to know that git servers you much better?

> If GNU decided to pull the plug on the
> git mirror I'll be inconvenienced. Just that. Is it necessary?

That's not the point, because I don't think anyone has talked of
"pulling the plug". Eli said it clearly: the onus of maintaining it
should not be on the Emacs developers, but in those wanting the
mirror.

    Juanma

Re: Git mirrors

[Jambunathan K]

The argument that getting up to speed on bzr will prevent one from
contributing to Emacs is quite baseless. The argument that a git access
will attract more contributors is also quite baseless.

What is absolutely critical for contribution is easy access to the
latest files. The specific version control system in use shouldn't
bother a user as the long as the intention of the user to contribute is
set in stone. 

To a casual or a one-off contributor *any* VCS - be it bzr, git or plain
old cvs - is a nuisance. To other contributors, the choice of VCS
shouldn't be a concern at all [1]. If it happens so that someone is
reluctant to digest a particular VCS, it only shows that the person
hasn't seen enough heterogenity in his projects or work setup.

I have contributed a few patches - a few liners basically - to
Emacs. Not knowing bzr didn't deter me. And it was not the availability
of the git mirrors for Emacs that I relied upon to turn in my first
patch.

I didn't want to install or learn bzr. I didn't want to download the
whole of Emacs repo either. I looked at loggerhead, downloaded the
latest version of the file through firefox, made the necessary changes
and turned in the patch. I used the same approach while git was unknown
to me and I wanted to turn in some patches for Orgmode.

Footnotes: 

[1] Over the course of the years, at various jobs/projects, I have used
Continuus, cvs, svn, clearcase, perforce, mercurial, git. I am sure that
this list will grow over the next few years.

In all the above setups (save for Continuus case) I have relied on Emacs
generic vc facilities to help me with the intial ramp.

To get up to speed on any *vcs* it's just enough if one knows how to
checkout, checkin and possibly revert. It should be a 10 minute job for
any user familiar with the basic VC paradigm.

One can hack even without using any VCS.
-- 

Re: Git mirrors

[Jambunathan K]

An infinite number of monkeys checking out from or checking in to a git
repo would never make GNU emacs a better program.

ps: Laugh it off. No offense intended.

Re: Git mirrors

[Stephen J. Turnbull]

This isn't relevant to Emacs decision-making, but unwarranted
git-bashing is no more helpful to people thinking about what to use in
their own projects than bzr-bashing is.

Juanma Barranquero writes:

 > And, by that token, I woudn't tout git, which is IMO the less
 > user-friendly for a beginner. I'd go so far as to say that using git
 > would "mak[e] harder to access or contribute to Free projects hosted
 > by GNU", as compared to bzr

In actual practice, I don't think that's true.  Witness the complexity
of BzrForEmacsDevs on the Emacs wiki.

git does indeed offer more rope for getting yourself in trouble, but
as long as you stick to the script, the basic git repertoire is only
slightly more complex but substantially more powerful than the
equivalent set of commands for bzr.  That means that your git workflow
doesn't need to change as often or abruptly as a bzr workflow does
when your role in a project changes (eg, from patch submitter to
committer, or from typo fixer to feature creature).  And git has a
simple model of commit (an "annotated cons") and branch (basically a
named variable whose value is a list), which makes predicting
performance and adapting workflows easy, and understanding complex git
commands like rebase and filter-branch and submodule *relatively*
easy.

bzr on the other hand has rather quirky performance characteristics,
depending on exactly how the plethora of internal caches are
implemented.  And many advanced DAG manipulation commands are simply
not available at all, which constrains private workflows.  (Of course
these commands can't be used on published branches, so their absence
doesn't constrain cooperative workflows much if at all.)

From the beginner's point of view, what git suffers from is fanboys.
People who use git tend to fall in love with the technology.  They're
*terrible* teachers, because no matter what you're trying to do,
they're always showing you nano-second optimizations and arcane
incantations.  (Still sounds like Emacs Lisp, eh?)  And they're not
great at writing docs, either.  Reference manuals, yes.  HOWTOs, no.

git's model is especially well-adapted to Emacs.  I think that (had
git been selected) after a short period of anguished cries of "who
designed this UI anyway, I'd like to setcdr his metacarpals!", Emacs
people would be doing well as a group and advanced git users would be
all over the community helping people do cool things (both gitwise and
in their Emacs feature branches and packages).  And there doesn't seem
to be anybody here with huge expertise in bzr itself, only enough to
explain how to fit into the Emacs workflow. :-(

IMO FWIW.

Re: Git mirrors

[Juanma Barranquero]

> This isn't relevant to Emacs decision-making, but unwarranted
> git-bashing is no more helpful to people thinking about what to use in
> their own projects than bzr-bashing is.

You say potato, I say warranted git-bashing.

> In actual practice, I don't think that's true.  Witness the complexity
> of BzrForEmacsDevs on the Emacs wiki.

Complexity? That page is almost sufficient to use Bazaar to develop
Emacs. "git help log" is several times longer.

> git does indeed offer more rope for getting yourself in trouble, but
> as long as you stick to the script, the basic git repertoire is only
> slightly more complex but substantially more powerful than the
> equivalent set of commands for bzr.  That means that your git workflow
> doesn't need to change as often or abruptly as a bzr workflow does
> when your role in a project changes (eg, from patch submitter to
> committer, or from typo fixer to feature creature).  And git has a
> simple model of commit (an "annotated cons") and branch (basically a
> named variable whose value is a list), which makes predicting
> performance and adapting workflows easy, and understanding complex git
> commands like rebase and filter-branch and submodule *relatively*
> easy.

That's git propaganda. You cannot seriously suggest that the git model
is universally simpler, just that you find it so. I'm glad for you. I
certainly had less trouble adapting to bazaar than git (and I was
already a git user the first time I tried bazaar).

> And there doesn't seem
> to be anybody here with huge expertise in bzr itself, only enough to
> explain how to fit into the Emacs workflow. :-(

That's not a problem. What we're interested in, is using bazaar for
the Emacs workflow. We can go daily working in Emacs without requiring
a huge expertise in bazaar. I'm not so sure with git. When I use it, I
spend quite a time looking (puzzledly) to man pages.

    Juanma

Re: Git mirrors

[Miles Bader]

Juanma Barranquero <lekktu@gmail.com> writes:
> That's git propaganda.

No.

-miles

-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: Git mirrors

[Juanma Barranquero]

On Fri, Oct 14, 2011 at 11:28, Miles Bader <miles@gnu.org> wrote:

> No.

Oh, yes, I forgot. git is universally, absolutely better. Not better
than bzr, just better in the widest possible meaning.

    Juanma

Re: Git mirrors

[Andreas Schwab]

Juanma Barranquero <lekktu@gmail.com> writes:

> Complexity? That page is almost sufficient to use Bazaar to develop
> Emacs. "git help log" is several times longer.

The Emacs manual is even longer.

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: Git mirrors

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > > In actual practice, I don't think that's true.  Witness the complexity
 > > of BzrForEmacsDevs on the Emacs wiki.
 > 
 > Complexity? That page is almost sufficient to use Bazaar to develop
 > Emacs. "git help log" is several times longer.

Different purposes; git help provides reference documentation, while
bzr help is just verbose usage messages.  I can tell you that writing
that BzrForEmacsDevs took not only a lot of reading of "bzr help"
pages, but also Bazaar website browsing, Googling for other docs, and
even experimentation with toy repos because the bzr help is horribly
imprecise and often just plain incomplete.  So, yes, even the set of
workflows suggested in that document is already complex.

 > That's git propaganda. You cannot seriously suggest that the git model
 > is universally simpler, just that you find it so.

Of course I'm suggesting that the *model* is universally simpler.  In
git, a project's history is "the DAG", and operations do the same
thing in every context because DAG is all there is.  More recent
versions of git add new concepts such as the reflog and submodules,
but these are extensions to the basic concept of DAG, not
modifications of it; they do not change the existing behavior of
commands in dealing with existing concepts.

In bzr, every repo format behaves subtly differently requiring
upgrades to formats (fortunately, the "2a" format seems to finally be
flexible enough to handle even colocated branches), and workspace
configuration (branch, bound branch, lightweight checkout) affects the
semantics of basic commands like "commit" dramatically.  There is no
single coherent model for bzr, let alone a simple one.

I do not claim that this simple model necessarily makes git easier to
use.  Clearly, many people use tools with only local models of their
behavior (aka "what works for me"), and bzr is quite good about
providing scads of UI features corresponding to such local models.  I
do not think that's a good approach for developing free software,
YMMV.  I would prefer to see the Bazaar project become a shell around
a simple repo format such as git's, offering the best of both worlds.

 > I certainly had less trouble adapting to bazaar than git

That's not not at all what I mean by model; that's "in use", for the
particular workflow you use.

 > We can go daily working in Emacs without requiring a huge expertise
 > in bazaar.

That is true for a subset of Emacs developers.  But this is
*obviously* a *proper* subset.  For other Emacs developers, their
daily workflows require a more powerful VCS.  Otherwise they would not
go to the trouble of maintaining multiple personal git and Arch
repositories, or trying to improve the Savannah git repo for Emacs.

The point here, which has been previously made by others, is not that
Emacs should switch now.  It's that encouraging[sic] people who really
like git to use Bazaar is not good for them, it's not good for Emacs,
it's not good for Bazaar, and it's not good for GNU[1].  It's a good idea
for Emacs to provide some support for the git mirror while "promoting"
the official Bazaar repository.

Footnotes: 
[1]  "Not good for GNU" is an opinion I currently hold but could
reasonably easily be convinced otherwise.  For example, Richard's
point that Bazaar admits use of GPLv3 (Gentoo says "GPL-2" for the
installed version here, so I guess that means that Bazaar uses the "or
later version at your option" wording in the permissions notice) is
important, but I'd be happier for GNU if v3 were the minimum version.

Re: Git mirrors

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Mon, 17 Oct 2011 16:19:28 +0900
> Cc: Óscar Fuentes <ofv@wanadoo.es>, rms@gnu.org,
> 	emacs-devel@gnu.org
> 
> Juanma Barranquero writes:
> 
>  > > In actual practice, I don't think that's true.  Witness the complexity
>  > > of BzrForEmacsDevs on the Emacs wiki.
>  > 
>  > Complexity? That page is almost sufficient to use Bazaar to develop
>  > Emacs. "git help log" is several times longer.
> 
> Different purposes; git help provides reference documentation, while
> bzr help is just verbose usage messages.  I can tell you that writing
> that BzrForEmacsDevs took not only a lot of reading of "bzr help"
> pages, but also Bazaar website browsing, Googling for other docs, and
> even experimentation with toy repos because the bzr help is horribly
> imprecise and often just plain incomplete.

Bazaar's docs really "need work®", but that doesn't mean git's don't.
In particular, being precise and complete doesn't necessarily mean
being helpful to a casual user.  See, for example

  http://netsplit.com/2009/02/17/git-sucks/

Try disregarding its obvious exaggeration and disgust, and just _read_
the portions of the man pages reproduced there.  I often find myself
in a similar conundrum, even though I never needed to do something as
complex as publish a branch.

>  > We can go daily working in Emacs without requiring a huge expertise
>  > in bazaar.
> 
> That is true for a subset of Emacs developers.  But this is
> *obviously* a *proper* subset.  For other Emacs developers, their
> daily workflows require a more powerful VCS.  Otherwise they would not
> go to the trouble of maintaining multiple personal git and Arch
> repositories, or trying to improve the Savannah git repo for Emacs.

That could well be out of habit, though.  Since the semantics and the
effects of most popular bzr commands are subtly different from their
git namesakes, and since the underlying models of the distributed
version control are also subtly different, I can understand how people
who have git wired into their minds and fingers become mad with bzr.
I understand that because I'm mad with git for the same reasons.

Re: Git mirrors

[Andreas Schwab]

Manpages are not tutorials, they are reference documentation.  If you
need a tutorial there are a lot of good ones available.

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: Git mirrors

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,  ofv@wanadoo.es,  lekktu@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Mon, 17 Oct 2011 10:31:33 +0200
> 
> Manpages are not tutorials, they are reference documentation.  If you
> need a tutorial there are a lot of good ones available.

Tutorial is not the issue here.  (Git does come with an official
tutorial man page.)  The issue here is that every command should be
explained in a way that is suitable both for the first reading by
someone inexperienced, and as reference material for someone
experienced who knows exactly what she is after.  I didn't find any
git documentation that fills the former niche (but I admit that I
didn't look too hard).

Look at the Emacs documentation, for example.  Would it be sufficient
to have just the TUTORIAL and then an alphabetical listing of all the
commands and options, each one with its doc string?  I don't think so.

Re: Git mirrors

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Tutorial is not the issue here.  (Git does come with an official
 > tutorial man page.)

Actually, it comes with three or so.  This is a problem ("quantity
before quality").

 > The issue here is that every command should be explained in a way
 > that is suitable both for the first reading by someone
 > inexperienced, and as reference material for someone experienced
 > who knows exactly what she is after.  I didn't find any git
 > documentation that fills the former niche (but I admit that I
 > didn't look too hard).

You won't get explanations for newbies for many git commands, because
they aren't commands.  They are actually internal functions, exposed
as commands because git's scripting language is POSIX shell.

Many commands do have reasonable introductions somewhere in the
tutorials, howtos, or man pages, but the organization of the
documentation leaves a lot to be desired.  You're absolutely right
that there's no rule for finding introductory material, you just have
to be lucky (or read everything, which is impractical to say the least).

Re: Git mirrors

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Manpages are not tutorials, they are reference documentation.  If you
>> need a tutorial there are a lot of good ones available.
>
> Tutorial is not the issue here.  (Git does come with an official
> tutorial man page.)  The issue here is that every command should be
> explained in a way that is suitable both for the first reading by
> someone inexperienced, and as reference material for someone
> experienced who knows exactly what she is after.

So you want those manpages to be both informative for inexperienced
users and a reference. That's unreasonable.

[snip]

> Look at the Emacs documentation, for example.  Would it be sufficient
> to have just the TUTORIAL and then an alphabetical listing of all the
> commands and options, each one with its doc string?  I don't think so.

You were talking about the documentation for commands, you let's pick a
random instance:

C-x k C-x 1

C-x 1 runs the command delete-other-windows, which is an interactive
compiled Lisp function in `window.el'.

It is bound to C-x 1, <menu-bar> <file> <one-window>.

(delete-other-windows &optional WINDOW)

Make WINDOW fill its frame.
WINDOW may be any window and defaults to the selected one.
Return nil.

[... it goes on referencing variables, etc... ]


It looks like a daunting piece of text for a beginner (what's a WINDOW?
what's a frame? Should I care about what it returns? And What's that
piece of text between the parenthesis, BTW?)

Actually, the docstring is a great reference. It's unreasonable to
expect all the relevant concepts explained because it would become a
mess as a reference, turning into a bad beginner's help text and as a
bad reference.

(Its "beginner-friendliness" character could be greatly improved with
tool-tips associated to some keywords, like in this case WINDOW and
frame. That would not cause annoyances to those more experienced users
who read the docstring for reference.)

Re: Git mirrors

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: Andreas Schwab <schwab@linux-m68k.org>,  stephen@xemacs.org, lekktu@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Mon, 17 Oct 2011 14:36:16 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Manpages are not tutorials, they are reference documentation.  If you
> >> need a tutorial there are a lot of good ones available.
> >
> > Tutorial is not the issue here.  (Git does come with an official
> > tutorial man page.)  The issue here is that every command should be
> > explained in a way that is suitable both for the first reading by
> > someone inexperienced, and as reference material for someone
> > experienced who knows exactly what she is after.
> 
> So you want those manpages to be both informative for inexperienced
> users and a reference. That's unreasonable.

No, it isn't unreasonable.  The GNU manuals are an example: they are
good both for the first reading and as a reference.

> C-x k C-x 1
> 
> C-x 1 runs the command delete-other-windows, which is an interactive
> compiled Lisp function in `window.el'.
> 
> It is bound to C-x 1, <menu-bar> <file> <one-window>.
> 
> (delete-other-windows &optional WINDOW)
> 
> Make WINDOW fill its frame.
> WINDOW may be any window and defaults to the selected one.
> Return nil.
> 
> [... it goes on referencing variables, etc... ]
> 
> 
> It looks like a daunting piece of text for a beginner (what's a WINDOW?
> what's a frame? Should I care about what it returns? And What's that
> piece of text between the parenthesis, BTW?)

Exactly my point: having just the doc strings of the commands is not
good enough as user documentation.

> Actually, the docstring is a great reference. It's unreasonable to
> expect all the relevant concepts explained because it would become a
> mess as a reference, turning into a bad beginner's help text and as a
> bad reference.

Exactly.  We are in agreement.  All I'm saying is that there should be
some more documentation, either in the man pages or in another
document.  Without that, a package of git complexity is almost
impenetrable.

Re: Git mirrors

[John Yates]

On Mon, Oct 17, 2011 at 8:36 AM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
> So you want those manpages to be both informative for inexperienced
> users and a reference. That's unreasonable.

That would be a reasonable stance if tutorials provided an
introduction of every concept.  Often they only cover a subset.  In
such cases the man pages are the _only_ documentation and thus a
newcomer's primary intro to more exotic features.  Recourse to
googling, experimenting, posting to news groups, etc. all suggest that
the reference documentation failed at some level.

/john

Re: Git mirrors

[Stephen J. Turnbull]

Eli Zaretskii writes:

 >   http://netsplit.com/2009/02/17/git-sucks/

Have you read the comments?  Every third one seems to point out that
git usability is almost as low as Emacsen!  Boy, git is really in bad
company there! :-)

 > Try disregarding its obvious exaggeration and disgust, and just _read_
 > the portions of the man pages reproduced there.

Sure (I don't need to, I've read them myself), but that's almost
irrelevant to introducing such a tool into the general workflow of a
project.  It has to be, because very few tools (even ones with a Daddy
Warbuck$$ like Canonical behind them) come with Emacs-quality docs.
Eg, bzr as you point out. ;-)

In practice I find this is not a huge problem for a free software
project's official VCS.  There will be a ${VCS}For${Project}Devs
document, and there will be people around who are able to walk
new/occasional devs through the workflow with the new tool.

You'll note that many of the people bitching in that blog are people
whose companies forced them to use git, or for whom participating in
the kernel workflow means using git.  I feel sorry for them because
(a) they're probably too busy to read the tutorials and (b) their
colleagues are too busy to answer questions.  Uh-oh, I see great pain
in their future....

 > I often find myself in a similar conundrum, even though I never
 > needed to do something as complex as publish a branch.

Publishing a branch with git is a real wart, granted (at least it most
certainly used to be).  But that's not a doc problem, it's a design bug.

I cannot sympathize with the "'Ref' say what???" issue, though; pretty
clearly the author wants git to present itself the same way that other
VCSes present themselves, and apparently didn't read the tutorial, so
doesn't know the first thing about git.  ("What is a 'ref'?" is indeed
the *first* thing about git -- it untangles almost *everything* in
git, including "repository corruption", which is usually a name for
"oops, I didn't keep a ref to that commit and now I can't find it").

 > [git people having trouble adjusting to bzr] could well be out of
 > habit, though.

It is most definitely not habit in my case.  It's lack of colocated
branches, and lack of technical documentation for pipelines and looms.
I need technical documentation because I have a very clear idea of
what workflows I want to implement, and the use cases and tutorials
published for those tools don't match my workflow.  Sadly it seems
pipelines can't do it (they're different from Mercurial queues) and
looms I've never figured out.

Re: Git mirrors

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: ofv@wanadoo.es,
>     lekktu@gmail.com,
>     rms@gnu.org,
>     emacs-devel@gnu.org
> Date: Mon, 17 Oct 2011 20:57:51 +0900
> 
>  > Try disregarding its obvious exaggeration and disgust, and just _read_
>  > the portions of the man pages reproduced there.
> 
> Sure (I don't need to, I've read them myself), but that's almost
> irrelevant to introducing such a tool into the general workflow of a
> project.

I didn't say it was relevant.  I was just reflecting on documentation
quality, separately from the rest of this thread.

>  > [git people having trouble adjusting to bzr] could well be out of
>  > habit, though.
> 
> It is most definitely not habit in my case.  It's lack of colocated
> branches, and lack of technical documentation for pipelines and looms.
> I need technical documentation because I have a very clear idea of
> what workflows I want to implement, and the use cases and tutorials
> published for those tools don't match my workflow.

That's still "habit" from my POV: you are used to certain workflows,
and bzr doesn't lend itself easily to those workflows.  Same happens
to me in git: I _want_ to have separate branches, but git forces me to
have a separate repo for each branch, if I insist on that workflow...

Re: Git mirrors

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > That's still "habit" from my POV: you are used to certain workflows,
 > and bzr doesn't lend itself easily to those workflows.

Well, you're welcome to lump muscle memory of particular options and
workflows that have been thought out and refined in practice together
if you like.  But to my mind workflows involving lightweight branching
(not really implemented in bzr yet) and lightweight checkouts/branches
bound to a remote repo (a fragile emulation is the best available in
git) are more than habit.

 > Same happens to me in git: I _want_ to have separate branches, but
 > git forces me to have a separate repo for each branch, if I insist
 > on that workflow...

Actually, it doesn't.[1]  And anyway a shared repo is a pure space
optimization; it doesn't offer any improvements in VC capability.
Since both git and bzr hardlink (when available) on local branching,
you probably don't even save that much space.  (Except that I don't
think hardlinks are available on Windows?)

Really, the only reason I can think of to let git affect your
preferred workflow is lightweight checkouts, which you can emulate on
a single filesystem[2] (including NFS or CIFS), but can't have using
SSH or HTTP as the network transport.

Footnotes: 
[1]  See the --shared and --reference, and --separate-git-dir options to
git-clone for a shared repo.

[2]  See the --separate-git-dir option to git-clone.

Looming colocation [Was: Git mirrors]

[Alan Mackenzie]

Hi, Stephen

On Mon, Oct 17, 2011 at 08:57:51PM +0900, Stephen J. Turnbull wrote:
> Eli Zaretskii writes:

>  > [git people having trouble adjusting to bzr] could well be out of
>  > habit, though.

> It is most definitely not habit in my case.  It's lack of colocated
> branches, and lack of technical documentation for pipelines and looms.
> I need technical documentation because I have a very clear idea of
> what workflows I want to implement, and the use cases and tutorials
> published for those tools don't match my workflow.  Sadly it seems
> pipelines can't do it (they're different from Mercurial queues) and
> looms I've never figured out.

Sorry if I'm a bit slow, but could you explain what a "colocated branch"
is, please?

Also, what is a "loom" in this context?

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

Looming colocation [Was: Git mirrors]

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Sorry if I'm a bit slow, but could you explain what a "colocated branch"
 > is, please?

"*A* colocated branch" doesn't really make sense; colocation is a
repository structure, not a branch property.  "Colocated branches" is
the way git normally operates: each repository contains a number of
branches which will be checked out in the same workspace at different
times.  To have two branches physically checked out at the same time,
you need to clone the repository (at least a whole branch).  In
Mercurial these are called "named branches".  Bazaar has an
experimental plugin called "coloc" which implements this (I think it's
about to become official in the next release or maybe in 2.6).

In the context of Mercurial or Bazaar, this is really just a way to
save space, and maybe a little bit of time, since you can compare
physically separate branches directly with "bzr diff $REMOTE_URL" or
get log information, etc.

In git, it plays two more important roles.  First, in git you can only
operate on branches (diff, merge, even log) when they are all present
in the same repository.[1]  Ie, colocation is fundamental to git's
design.  Second, in combination with refs (ie, a variable containing a
revision ID), it makes DAG manipulations like rebase potentially safe
and efficient (as long as you keep them within one repo).  Do you want
to do something dangerous with your master branch?  Just "git branch
saved-master master" (which is as cheap as "cp .git/refs/heads/master
.git/refs/heads/saved-master"), do it, and if something disastrous
happens, "git branch -f master saved-master" and you're back where you
started.

It is possible to do this in bzr as well, but it's not documented, and
not part of the official UI.

 > Also, what is a "loom" in this context?

"loom" is an established but not so widely-used bzr plugin.  It allows
you to create a stack of groups of provisional changes which are
version-controlled (and so can be pulled into another branch; I think
push is inhibited for the same kinds of reasons that people prefer to
require that push be a fast-forward, but I'm not sure).

The idea is that you have a new feature you want to implement in CC
mode.  This requires some low-level infrastructure refactoring which
is generally useful.  So you create a "thread" called "refactor".  You
do the work, committing changes in coherent chunks as usual.  Now
you're ready to implement the feature.  So you create another thread
"on top of" refactor, called "feature".

OK, so midway through the implementation of feature, after a couple
more commits, you realize that you got refactor wrong.  Now you do
"down-thread", which pops off all the changes you made in feature so
far (but saves them).  This leaves you at the same state as when you'd
just finished refactor.  You fix the bug or add the extra feature,
then do "up-thread" which automatically restores the popped changes.
(This could result in a merge conflict, which you'd have to fix.)

I believe that loom keeps track of how much progress is made on each
thread, creating conceptual links that cross threads.  Thus you have
warp and woof being woven together, and the tool that manages such
weaving is, of course, a loom.

So this is like the famous "quilt" program, but the patches are
version controlled.  Another way to look at it, maybe, is a sort of
domesticated rebase.

Maybe Barry Warsaw will chime in, as I know he loves loom, and I've
never fully understood it or used it in anger.

Footnotes: 
[1]  This is actually true of hg and bzr, too.  The difference is that
git requires an explicit fetch (or pull) of the required branches in
advance, and then the reference to the fetched branch is durable -- if
you don't want that, you have to explicitly delete it.  In hg and bzr,
the fetch occurs implicitly as an internal step in diff or merge, and
the remote branch data is thrown away after a diff, or remains
implicitly in the internal DAG after a merge.  In a diff, it may be
possible to do a partial fetch, as well; I haven't thought about it
carefully.  But for a merge, obviously you have to fetch all of the
history and content data in order to incorporate it in the merged DAG.

It would be easy to emulate the hg/bzr style in git with a script.

Re: Looming colocation [Was: Git mirrors]

[Barry Warsaw]

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

On Oct 18, 2011, at 01:59 AM, Stephen J. Turnbull wrote:

>"loom" is an established but not so widely-used bzr plugin.  It allows
>you to create a stack of groups of provisional changes which are
>version-controlled (and so can be pulled into another branch; I think
>push is inhibited for the same kinds of reasons that people prefer to
>require that push be a fast-forward, but I'm not sure).

You can definitely push looms to Launchpad, and anyone else can pull them from
Launchpad as long as they also have the loom plugin installed.

>Maybe Barry Warsaw will chime in, as I know he loves loom, and I've
>never fully understood it or used it in anger.

I think you got it pretty much right, but also see my other followup.

FWIW, I used looms a lot when I was working on Launchpad because there feature
work can sometimes be pretty complex, often touching multiple layers of the
system.  I prefer to work on such layers independently, precisely as you
describe.  A great use case for this is where different layers need to be code
reviewed by different experts.  E.g. you wouldn't want to mix UI changes into
database schema diffs.

For simpler code bases, looms tend not to be that useful (but no harm in
leaving the plugin sit around).  Sometimes I'll use looms when merging in
other people's work to Mailman 3 because it lets me keep my own integration
work above and below their branch separated.  I'll also use them in cases like
you describe, where a particular new feature requires some prerequisite
refactoring work that would ordinarily clutter up the real meat of your
current changes.

-Barry

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

Looms and Pipelines (was Re: Git mirrors)

[Barry Warsaw]

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

On Oct 17, 2011, at 08:57 PM, Stephen J. Turnbull wrote:

>It is most definitely not habit in my case.  It's lack of colocated
>branches, and lack of technical documentation for pipelines and looms.
>I need technical documentation because I have a very clear idea of
>what workflows I want to implement, and the use cases and tutorials
>published for those tools don't match my workflow.  Sadly it seems
>pipelines can't do it (they're different from Mercurial queues) and
>looms I've never figured out.

I personally dislike colocated branches, and it's one of the things that
drives me crazy about using Python's Mercurial repo.  I always end up
splitting it into one-branch-per-directory, but twisting the tool's basic
workflow model into my own comfortable workflow causes problems (e.g. a recent
commit of mine where I somehow managed to double-merge a branch).

That aside, I recognize that some people really like colocated branches, so
I'm glad bzr is going to have support for them in the next release.

Looms and pipelines provide different use cases, IMO.  Both are useful for
managing a "stack" of related but separable changes.  Imagine you need to make
a change to your database, your model, and your UI.  These different layers
can be represented in that stack of branches.  You start by making a change in
the database and commit those, then move up to make a related change in your
model, and commit those.  When you get to your UI changes, you realize that
your database is missing something critical, so you pop back down to that
layer and make the change.  Then using pipelines/looms, you jump back up the
stack, and let bzr automatically merge your database layer changes to every
branch up the stack.

Why manage these as a stack of related changes, i.e. branches?  For one thing,
it lets you have smaller, more manageable, more reviewable changes.  Maybe you
want to share your database changes without sharing your UI changes.  Maybe
someone else beat you to committing the model changes, but your other changes
are still relevant.  Maybe someone changed the public API between the model
and UI and you'd like to merge their changes in at the appropriate layer, but
keep them separate from your own changes.  Maybe you just want to look at a
diff of the model changes and ignore everything above and below.  Looms and
pipelines help with all the nasty bookkeeping that you'd normally be forced to
do to keep all the relationships together.

I'd say that the primary difference between pipelines and looms is that the
latter version controls those relationships.  I.e. the metadata that describes
those relationships between your stacked branches is under bzr.  That means
you can share, push, publish, and pull a loom as one unit, maintaining those
relationships.  Yes, you can also separate your stacked branches (called
"threads" in loom terminology), into completely independent branches.

Pipelines on the other hand, don't version control that metadata, but the
advantage is that every branch in a pipeline is a completely normal Bazaar
branch, so there's not much special about them.  OTOH, if you're going to pull
a loom from me, you need to have the plugin installed locally because threads
*are* special.

If you're familiar with the Debian quilt system, there is a *lot* of
similarity between looms/pipeline and quilt.  So much in fact, that the bzr
team is considering using looms/pipelines as a mapping to quilts for Ubuntu's
source branches on Launchpad.

The major disadvantage of both looms and pipelines is that they are currently
implemented as plugins, and while they are kept up-to-date and compatible with
new bzr releases, I'm hopeful that at some point the loom feature (which I
prefer) will be brought into core bzr.

Note too that loom/pipeline are completely optional for any particular branch
you work on.  You can still install the plugins and use vanilla bzr, since you
need to initialize a branch to use (e.g.) looms explicitly.

Cheers,
-Barry

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

Re: Git mirrors

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > Are you seriously comparing Solitaire with a VCS?

No, he's exaggerating.  Nevertheless, the GNU system envisioned in the
GNU Manifesto was much less ambitious than what we see today.  GNU
clearly has experienced orders of magnitude mission creep, but the
resources devoted to the core mission (software freedom) are now way
too small.  Cf. Miles' and my posts questioning acceptance of Bazaar
as a GNU project.

 > Most software projects are mainained with the help of a VCS, and if
 > chosing one as "official", a DVCS seems more sensible than a
 > non-distributed one.

For sure.  And GNU now has two.  GNU Arch (since 2003), a definitely
freedom-loving project.  And GNU Bazaar (just in time to be adopted by
Emacs; coincidence?)  For heaven's sake, even the name "Bazaar" evokes
open source ideals!

 > I really dislike this argument, because it means that people who wants
 > to contribute to some free software project will avoid to do so
 > because it does not use their tool of choice.

I don't understand what you're trying to say.  Óscar is precisely
arguing that there should be *no* "official" GNU VCS, because there
are too many good ones out there.

 > > by sending the message to other creators of Free Software that
 > > GNU is out there to aggressively compete with them regardless of
 > > merit.)
 > 
 > GNU software is out there to aggressively compete, and win the users,
 > yes (at least the ones that care about freedom too). "Regardless of
 > merit" is meaningless, because the users will chose the one which best
 > fits their needs.

That's precisely Óscar's point, though.  If users are choosing
something other than GNU, and it's clear that GNU makes choices based
on favoritism toward GNU-labeled projects, that makes the GNU
recommendation meaningless as a signal of quality.  It's already
meaningless as a signal of the freedom of the software, since that is
determined quite precisely by the license; no need for a GNU label.

That leaves the GNU label as a signal of "political correctness" on
the part of the *project* (*not* the software, which is *free* by
assumption) and maybe "personal relationship to RMS" (not that RMS
would refuse git because he doesn't like Linus, rather the other way
around).  While I understand it's not a *contradiction* in this
context, the justaposition of emphasizing political correctness while
advocating freedom is, uh, unattractive.

It would be (economically) better if GNU developers making (currently)
inferior software were encouraged to abandon their effort, and devote
some of that time to improving the free rival(s), and most of it to
developing software that currently has no attractive free
implementation.  Somebody else will have to explain the reasons for
overriding the economics here, because it's not that "the economically
better software is non-free".

 > which is to say that Savannah is doing a better job of supporting git
 > than Bazaar... That does not seem entirely compatible with the view
 > that GNU is rejecting git or favoring Bazaar.

Richard has already announced here that he thinks Savannah made a
mistake.  He has clearly stated the policy: GNU does not reject git,
but it does favor Bazaar.

 > But that was then. Currently, wanting to hack Emacs and not wanting to
 > use Bazaar seems a bit childish IMO. Yes, you'd prefer to use git. I
 > would prefer for Emacs to be written in Ada. I'll have to adapt. Can
 > you?

Sure.  But your analogy fails, because the problem here is not whether
Óscar can *adapt* to Emacs' use of bzr.  He can, and he can use git
(for developing Emacs) at the same time as bzr (for pushing his
contributions) if he wants to.

The problem is that many people are failing to *conform*.  They're
*adapting* by using a git mirror, and annoying larsi and Glenn et al
by reporting bugs against git revision ids.  John is trying to reduce
or eliminate the annoyance by providing a canonical git repo with a
publicly available git revid <-> bzr revid map.

Richard's reluctance to express approval of this idea strikes me as
going beyond *promoting* GNU Bazaar to *protecting* it.

Re: Git mirrors

[Juanma Barranquero]

On Fri, Oct 14, 2011 at 06:50, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> No, he's exaggerating.

With a purpose.

> For sure.  And GNU now has two.  GNU Arch (since 2003), a definitely
> freedom-loving project.  And GNU Bazaar (just in time to be adopted by
> Emacs; coincidence?)  For heaven's sake, even the name "Bazaar" evokes
> open source ideals!

And?

> I don't understand what you're trying to say.  Óscar is precisely
> arguing that there should be *no* "official" GNU VCS, because there
> are too many good ones out there.

I'm trying to say the same thing that Jambunathan K just said: that
the project's choice of a DVCS over another will only stop from
participating to those who weren't really inclined to do so in the
first place.

> If users are choosing
> something other than GNU, and it's clear that GNU makes choices based
> on favoritism toward GNU-labeled projects, that makes the GNU
> recommendation meaningless as a signal of quality.

*Technical* quality, perhaps. But the recommendations are not just
technical, and someone who choses GNU software should know it. And the
technical aspect will in most cases improve over time.

> It's already
> meaningless as a signal of the freedom of the software, since that is
> determined quite precisely by the license; no need for a GNU label.

That's not an argument against having a GNU DVCS, it is an argument
against having GNU in the first place.

> While I understand it's not a *contradiction* in this
> context, the justaposition of emphasizing political correctness while
> advocating freedom is, uh, unattractive.

I don't think so, as long as political correctness is a choice.

> It would be (economically) better if GNU developers making (currently)
> inferior software were encouraged to abandon their effort, and devote
> some of that time to improving the free rival(s)

Isn't that a recipe for monocultures? Or are you suggesting that all
XEmacs developers should abandon it, sign papers and start hacking
Emacs?

> and most of it to
> developing software that currently has no attractive free
> implementation.

By and large, people develops what they are interested in. There's
nobody in charge to order or suggest them to tackle other software
that would be useful.

> Richard has already announced here that he thinks Savannah made a
> mistake.  He has clearly stated the policy: GNU does not reject git,
> but it does favor Bazaar.

Yes, that's what Richard said. But still, he does not order around the
Savannah hackers (or we would have had an upgrade to the bazaar server
almost two years before). The fact is that currently, Savannah is not
favoring bazaar.

> But your analogy fails, because the problem here is not whether
> Óscar can *adapt* to Emacs' use of bzr.  He can, and he can use git
> (for developing Emacs) at the same time as bzr (for pushing his
> contributions) if he wants to.

Apparently, for Óscar is a problem.

> The problem is that many people are failing to *conform*.  They're
> *adapting* by using a git mirror, and annoying larsi and Glenn et al
> by reporting bugs against git revision ids.  John is trying to reduce
> or eliminate the annoyance by providing a canonical git repo with a
> publicly available git revid <-> bzr revid map.

My view of that people is that it's as if I were to use a C-to-Ada
translator to get the code of Emacs, patch it (in Ada), and complain
that it is difficult to integrate the changes back into Emacs because
they are rejected or I'm forced to convert them back into C. I'm
making my live difficult, I'm making the live of others difficult, and
I'm complaining about it. And, BTW, "failing to *conform*" is quite
loaded, don't you think?

> Richard's reluctance to express approval of this idea strikes me as
> going beyond *promoting* GNU Bazaar to *protecting* it.

And you're surprised that Richard is protective of GNU because...?

    Juanma

Re: Git mirrors

[Bastien]

Juanma Barranquero <lekktu@gmail.com> writes:

> I'm trying to say the same thing that Jambunathan K just said: that
> the project's choice of a DVCS over another will only stop from
> participating to those who weren't really inclined to do so in the
> first place.

If all contributors were just small contributors, that would be true.

But the impact of using bzr for GNU Emacs is not the same for small
contributors and for package maintainers.

I am trying to maintain org-mode in my free time, and I can tell how
maintainance would be a lot easier if Emacs were using git.  

Okay, the fact that GNU Emacs uses bzr is no excuse for the recent
delays in merging Org -- the real reason is my lack of free time -- 
but it definitely doesn't make things easier.

-- 
 Bastien

Re: Git mirrors

[Juanma Barranquero]

On Fri, Oct 14, 2011 at 14:29, Bastien <bzg@altern.org> wrote:

> But the impact of using bzr for GNU Emacs is not the same for small
> contributors and for package maintainers.

Fair enough. Though if we used git, package maintainers using Bazaar
in their repos would have the same burden. It's a no-win situation.

    Juanma

Re: Git mirrors

[Bastien]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Oct 14, 2011 at 14:29, Bastien <bzg@altern.org> wrote:
>
>> But the impact of using bzr for GNU Emacs is not the same for small
>> contributors and for package maintainers.
>
> Fair enough. Though if we used git, package maintainers using Bazaar
> in their repos would have the same burden. It's a no-win situation.

Fair enough :)

-- 
 Bastien

Re: Git mirrors

[Eli Zaretskii]

> From: Bastien <bzg@altern.org>
> Date: Fri, 14 Oct 2011 14:29:31 +0200
> Cc: Óscar Fuentes <ofv@wanadoo.es>,
> 	"Stephen J. Turnbull" <stephen@xemacs.org>, rms@gnu.org,
> 	emacs-devel@gnu.org
> 
> I am trying to maintain org-mode in my free time, and I can tell how
> maintainance would be a lot easier if Emacs were using git.  

Is it just because these are two different VCSes, or are there other
reasons?

Re: Git mirrors

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

>> I am trying to maintain org-mode in my free time, and I can tell how
>> maintainance would be a lot easier if Emacs were using git.  
>
> Is it just because these are two different VCSes, or are there other
> reasons?

Well, the objective reason is that these are two different VCSs, and 
the subjective one is that I'm more familiar with git than with bzr.

-- 
 Bastien

Re: Git mirrors

[Stephen J. Turnbull]

Juanma Barranquero writes:
 > On Fri, Oct 14, 2011 at 06:50, Stephen J. Turnbull <stephen@xemacs.org> wrote:

 > > For sure.  And GNU now has two.  GNU Arch (since 2003), a definitely
 > > freedom-loving project.  And GNU Bazaar (just in time to be adopted by
 > > Emacs; coincidence?)  For heaven's sake, even the name "Bazaar" evokes
 > > open source ideals!
 > 
 > And?

The reason for cutting off discussion of what is good for Emacs (and
more generally, for GNU) was that Bazaar was a GNU project which
wasn't totally useless as a VCS in the context of Emacs traditional
workflow, although at the time performance was known to suck, which
took years to get fixed (mostly not not Bazaar's fault).  But Arch was
a tried and tested alternative, with a much longer history, a history
of actively supporting GNU goals, and an existing and well-tested
repository.

 > > I don't understand what you're trying to say.  Óscar is precisely
 > > arguing that there should be *no* "official" GNU VCS, because there
 > > are too many good ones out there.
 > 
 > I'm trying to say the same thing that Jambunathan K just said: that
 > the project's choice of a DVCS over another will only stop from
 > participating to those who weren't really inclined to do so in the
 > first place.

"Stop participating" is a strawman.  It's an exaggeration by folks who
claim it will happen, and now you turn around and again take it
absolutely and point out that it's greatly exaggerated, then
exaggerating that fact yourselves, into a claim of falsehood.  As
usual, the truth is somewhere in the middle, and IMO that truth
matters in practice.

The thing is, every minute spent on working around an inefficient
workflow is a minute that is not spent developing free software.  It
also changes the "price" of working on a particular project; if one
can use their VCS of choice in project A, and one they dislike
intensely in project B, project A will get more time than it otherwise
would, and project B less.  People will waste more time recovering
from mistakes in a VCS they don't like, etc.

Of course as you pointed out to Bastien, this door swings both ways.
So it's not an argument for switching to git, rather the reverse, as
many Emacs developers have come to like bzr AFAICT.

On the other hand, protecting bzr by discouraging use of git mirrors,
and git as the primary VCS by projects whose developers generally
prefer it, is costly to the GNU Project as a whole, by discouraging
(though not preventing) git fans from working on projects that conform
to the "use Bazaar" policy in spite of their own wishes.

All clear now?

 > > If users are choosing something other than GNU, and it's clear
 > > that GNU makes choices based on favoritism toward GNU-labeled
 > > projects, that makes the GNU recommendation meaningless as a
 > > signal of quality.
 > 
 > *Technical* quality, perhaps. But the recommendations are not just
 > technical,

Of course they're not, and in fact they are *primarily* nontechnical.
I'm simply saying that being a signal of technical quality is
something GNU *should* aim at, even though it *must* be a secondary
goal for GNU.

 > > It's already meaningless as a signal of the freedom of the
 > > software, since that is determined quite precisely by the
 > > license; no need for a GNU label.
 > 
 > That's not an argument against having a GNU DVCS,

Nobody claimed it is, just that there's no "pro" argument here.

 > it is an argument against having GNU in the first place.

Of course it's not!  While determining whether any one program is free
is relatively simple, it is a *huge* service to have a full system
delivered, and have confidence that everything in that system is free
software.

 > > It would be (economically) better if GNU developers making (currently)
 > > inferior software were encouraged to abandon their effort, and devote
 > > some of that time to improving the free rival(s)
 > 
 > Isn't that a recipe for monocultures?

That depends on the destination project(s).  In the case of OS kernels
and VCSes, I don't think the world at large would notice, or lose any
biodiversity if the development organizations of the HURD and Bazaar
simply disbanded but left their repos and tarballs archives in place.
Canonical customers would probably be disgusted, though.

 > Or are you suggesting that all XEmacs developers should abandon it,
 > sign papers and start hacking Emacs?

Hello, Eli!  We are now in the near vicinity of "ad hominem" (though
this *still* isn't an ad hominem).

No, I don't suggest that.  Abandon XEmacs, maybe, sign papers, maybe,
but I doubt that switching to Emacs would do anybody much good.

 > > But your analogy fails, because the problem here is not whether
 > > Óscar can *adapt* to Emacs' use of bzr.  He can, and he can use git
 > > (for developing Emacs) at the same time as bzr (for pushing his
 > > contributions) if he wants to.
 > 
 > Apparently, for Óscar is a problem.

Why do you keep ignoring what he writes?  Yes, he *wishes* Emacs used
git, but in this thread, he wants to know why GNU uses a policy that
appears to him to be counterproductive in a number of ways.

 > And, BTW, "failing to *conform*" is quite loaded, don't you think?

Sure.  It's accurate, though.  Richard hasn't said that using git is
Evil, nor that GNU projects *must* use bzr.  He'd just like to
"discourage" git use and "encourage" bzr use, whether or not the
individual projects and developers think that is good for them.  Doing
what the collective does at the expense of one's own interests is
accurately called "conforming".

 > > Richard's reluctance to express approval of this idea strikes me as
 > > going beyond *promoting* GNU Bazaar to *protecting* it.
 > 
 > And you're surprised that Richard is protective of GNU because...?

Of course Richard protects *GNU*, and nothing I have written should
give you the impression that I think that is anything but an
unqualified good.  Nor am I *surprised* that he protects individual
GNU projects; he has never been a fan of unbridled competition, and he
clearly favors somewhat tighter bridles than I do. :-)

I do think it's unfortunate that he makes a point of protecting GNU
Bazaar because (a) as a general principle I believe it harms GNU to
protect individual GNU projects from outside competition on merit,
just as any society with too many protected segments becomes weaker as
a whole, and (b) because Bazaar in particular is not an essential part
of the GNU system given the availability of several excellent free
alternatives, while the Bazaar project is hardly an enthusiastic
promoter of the GNU Project or its goals.  As far as their marketing
goes they emphasize cross-platform support (especially Windows
support), Launchpad, and Ubuntu, not GNU, and they almost never
mention software freedom (although of course they make a big deal that
their software is free software).

Re: Git mirrors

[Vijay Lakshminarayanan]

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

>  > > But your analogy fails, because the problem here is not whether
>  > > Óscar can *adapt* to Emacs' use of bzr.  He can, and he can use git
>  > > (for developing Emacs) at the same time as bzr (for pushing his
>  > > contributions) if he wants to.
>  > 
>  > Apparently, for Óscar is a problem.
>
> Why do you keep ignoring what he writes?  Yes, he *wishes* Emacs used
> git, but in this thread, he wants to know why GNU uses a policy that
> appears to him to be counterproductive in a number of ways.

I think Óscar's questions have been answered.  I think he has also made
it quite clear that he doesn't fully understand the goals of the GNU
project.  For instance, in one post, he bemoaned the fact that GNU's
wasn't focusing on "users" even though "users" were its greatest focus.
Richard responded with, IMO, a good example comparing Skype helping
users but not helping users freedoms.

Hopefully Óscar understands the GNU project better with this thread.
That will be, IMO, the only good thing to come out of this huge
flamewar.

-- 
Cheers
~vijay

Gnus should be more complicated.

Re: Git mirrors

[Óscar Fuentes]

Vijay Lakshminarayanan <laksvij@gmail.com> writes:

> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>
>>  > > But your analogy fails, because the problem here is not whether
>>  > > Óscar can *adapt* to Emacs' use of bzr.  He can, and he can use git
>>  > > (for developing Emacs) at the same time as bzr (for pushing his
>>  > > contributions) if he wants to.
>>  > 
>>  > Apparently, for Óscar is a problem.
>>
>> Why do you keep ignoring what he writes?  Yes, he *wishes* Emacs used
>> git, but in this thread, he wants to know why GNU uses a policy that
>> appears to him to be counterproductive in a number of ways.
>
> I think Óscar's questions have been answered.

No.

> I think he has also made
> it quite clear that he doesn't fully understand the goals of the GNU
> project.  For instance, in one post, he bemoaned the fact that GNU's
> wasn't focusing on "users" even though "users" were its greatest focus.
> Richard responded with, IMO, a good example comparing Skype helping
> users but not helping users freedoms.

And that makes cristal clear that you don't understand my
questions. Those involve *always* Free vs Free software, including
"GPLvX and later" vs "GPLvX and later". So the reference to Skype is
just another attempt at sidetracking the questions.

> Hopefully Óscar understands the GNU project better with this thread.
> That will be, IMO, the only good thing to come out of this huge
> flamewar.

Flamewar who? I made a series of questions about how GNU policies affect
non-GNU *FREE* software and how that fits the Free Software cause as a
whole. Because GNU is just an instrument of the FSF to promote Free
Software, and that may be at odds with such policies. Some people
(including you) insist on talking about unrelated issues (Skype,
my-dvcs-is-better-than-yours, etc.)

This is the second time that I make a question about core Free Software
issues on this list. Not only is this off-topic (for which I sincerely
apologize) but the result on both cases was just a gust of hot air with
some mixed sulfur.

Please note that I'm restraining myself from following up most
messages. And no more questions. I promise.

Re: Git mirrors

[Juanma Barranquero]

On Mon, Oct 17, 2011 at 20:39, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Flamewar who?

And, which flamewar? Not every discussion is a flamewar just because
it's a bit more heated that the baseline ones.

> Some people
> (including you) insist on talking about unrelated issues (Skype,
> my-dvcs-is-better-than-yours, etc.)

To be fair, you said: "To the point of not only promoting a
technically inferior package (i.e. bzr)". That's quite
my-dvcs-is-better-than-yours-y.

> This is the second time that I make a question about core Free Software
> issues on this list. Not only is this off-topic (for which I sincerely
> apologize)

I think Richard has said several times that it is on-topic to discuss
free software policies in this list.

    Juanma

Re: Git mirrors

[Stefan Monnier]

> I think Richard has said several times that it is on-topic to discuss
> free software policies in this list.

I think it's only marginally on-topic and would prefer if people could
keep such threads to a minimum.  There's gnu.misc.discuss for
general discussions.


        Stefan

Re: Git mirrors

[Richard Stallman]

    > I think Richard has said several times that it is on-topic to discuss
    > free software policies in this list.

In general, the place for such discussion is gnu-misc-discuss, not
here.  In this list, it is proper to explain how GNU policies apply to
Emacs development.  To argue about whether the policies are good ones,
please use gnu-misc-discuss.

-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Git mirrors

[Vijay Lakshminarayanan]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Vijay Lakshminarayanan <laksvij@gmail.com> writes:
>
>> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>>
>>>  > > But your analogy fails, because the problem here is not whether
>>>  > > Óscar can *adapt* to Emacs' use of bzr.  He can, and he can use git
>>>  > > (for developing Emacs) at the same time as bzr (for pushing his
>>>  > > contributions) if he wants to.
>>>  > 
>>>  > Apparently, for Óscar is a problem.
>>>
>>> Why do you keep ignoring what he writes?  Yes, he *wishes* Emacs used
>>> git, but in this thread, he wants to know why GNU uses a policy that
>>> appears to him to be counterproductive in a number of ways.
>>
>> I think Óscar's questions have been answered.
>
> No.

That surprises me.  Quoting an exchange we had earlier:

,----
| > For the nth time: I want to know why such policy is considered good for
| > the Free Software cause (being GNU an instrument of such cause), 
| 
| The reason to support GNU projects over others is that it is the stated
| goal of GNU that all distributed software should be Free and copylefted
| by law.  To this end, any software project that shares the same goals
| will be supported.
`---- http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00527.html

[snip]

>> Hopefully Óscar understands the GNU project better with this thread.
>> That will be, IMO, the only good thing to come out of this huge
>> flamewar.
>
> Flamewar who? 

You have people citing comments by each other and calling them ad
hominem.  You have exchanges calling git/bzr
unusable/unintuitive/broken.  There's more.  All the characteristics of
a flamewar to me.  Note: I didn't say /you/ alone were responsible for
the entire flamewar.  (A one man flamewar has a better name: troll ;-) )

> I made a series of questions about how GNU policies affect
> non-GNU *FREE* software and how that fits the Free Software cause as a
> whole. Because GNU is just an instrument of the FSF to promote Free
> Software, and that may be at odds with such policies. Some people
> (including you) insist on talking about unrelated issues (Skype,
> my-dvcs-is-better-than-yours, etc.)

Richard's comments about the git vs bzr:

,----
| Git is simply a rival.  We are not against it, but GNU Project
| activities ought to promote the GNU package for this job.
`---- http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00616.html

,----
| >     I always thought that Free Software is about the user, always the
| >     user.
| >
| > The free software movement campaigns for users' freedom.
| > So you could say it is "about the users' freedom".
`---- http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00659.html

Your follow up question to the above was:

,----
| How does it help the Free Software cause to privilege projects over
| other Free alternatives putting merit aside just because they have the
| GNU label sticked on them?
`----

I think I've answered this.

-- 
Cheers
~vijay

Gnus should be more complicated.

Re: Git mirrors

[Stephen J. Turnbull]

Vijay Lakshminarayanan writes:

 > I think Óscar's questions have been answered.

Not at all.  The "why" of the policy has not been touched by anybody,
except by an appeal to authority and circular arguments.

 > For instance, in one post, he bemoaned the fact that GNU's wasn't
 > focusing on "users" even though "users" were its greatest focus.

No, I don't think that is fair.  This is a very difficult point, and
the nomenclature doesn't help.  Specifically, "software freedom" and
"free software" are both tropes; they do not describe any actual
entity.  Richard has often been at pains to explain that, despite the
names, *software* is neither free nor non-free.[1]  Rather, *the legal
system or licenses* can provide or deny freedom to use (including
developing) software to *people* (ie, users).  It is not surprising
that it is difficult to express oneself in this context.  On top of
that, I suspect that Óscar, while I would characterize him as
"fluent", is probably not a native speaker.

I suspect that a more general statement of what Óscar wanted to ask
is, "Should not the GNU Project take measures that increase awareness
of GNU among users, in particular improving efficiency so we can
provide more and better software?"  Or, more pointedly, "aren't we
abdicating our responsibility to market our product?"

 > Hopefully Óscar understands the GNU project better with this thread.
 > That will be, IMO, the only good thing to come out of this huge
 > flamewar.

I beg you to look harder.  Any number of good things will come of it,
though not necessarily directly beneficial to Emacs.  In particular,
*you* learned something, but there are other benefits, including a
better understanding of a central tool in the workflow, and off-list
negotiations to better promote the GNU Project.

Footnotes: 
[1]  In the context of slogans like "software wants to be free."

Re: Git mirrors

[Jambunathan K]

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

> Vijay Lakshminarayanan writes:
>
>  > I think Óscar's questions have been answered.
>
> Not at all.  The "why" of the policy has not been touched by anybody,
> except by an appeal to authority and circular arguments.

The way it works in a social setup is someone complains, it is noted but
*not* acted upon *immediately*. Someone else complains sometime
later. It gets noted again but *nothing* happens. More people start
complaining at which point the contentious issue gets some primacy. The
policy may be reviewed and changes may be effected *going forward*.

(Note: "A complaint" in the eariler para could also be replaced with "a
leak in the system" or an "exeptional scenario or a situation".)

This is how incremental adjustments are made to policy/law etc once
there is a base working model. So in respect of incremental improvements
based on observing the system behaviour, a policy/law is not unlike
software.

I would summarize Oscar's arguments as follows - This is Oscar speaking
-

The *existing precedent* of a GNU project encouraging a sister project
(by using it) solely based on the sister project's license criterion (or
ideological affirmations) has implications for adoption of the project
in question. Has this consideration been factored in to while the
current precedent was set in motion. If not - which I am confident is
the case - can this situation be changed? Emacs is a mature and already
a popular project so the impact on "adoption" does not arise. What if
the project in question is a *totally* new or the "in works" GNU project
- arguably a project labelled as "high priority". Will it's adoption
suffer merely because it went with a lesser known and not so popular
VCS.

> I beg you to look harder.  Any number of good things will come of it,
> though not necessarily directly beneficial to Emacs.  In particular,
> *you* learned something, but there are other benefits, including a
> better understanding of a central tool in the workflow, and off-list
> negotiations to better promote the GNU Project.

IMO, the reason Oscar continued to exchange mails was this: an implicit
assumption that the existing system will be overthrown or replaced as
soon as his request/warning is registered. This is not how things
work. 

If something is not "utterly" broken, it is not going to be fixed
immediately or fixed at all. bzr isn't broken and it would be naive of
anyone to expect that it will be replaced. 

The reason others - the experienced ones, such as Stephen or others -
continued to exchange mails was to throw some weight around the
argument, to refine their own understanding or to share or discover new
facts or simply to help Oscar articulate his ideas better or to stress
test his arguments to see whether it withstands some onslaught.

On the whole, the discussion was a healthy one even though it veered a
bit.

Jambunathan K.
-- 

Re: Git mirrors

[Richard Stallman]

    I suspect that a more general statement of what Óscar wanted to ask
    is, "Should not the GNU Project take measures that increase awareness
    of GNU among users, 

We try to take measures to increase awareness of GNU among users.  One
of them is that GNU Projects should promote other GNU Projects.
Other methods can be useful too.

			in particular improving efficiency so we can
    provide more and better software?"

I don't see that it relates very much to increasing awareness of GNU.
However, making programs more efficient is desirable in its own right.

-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Git mirrors

[Richard Stallman]

    How does it help the Free Software cause to privilege projects over
    other Free alternatives putting merit aside just because they have the
    GNU label sticked on them?

1. It makes the GNU Project as a whole more successful and thus more
influential.

2. Encouraging the success of a DVCS that allows GPLv3, over one that
doesn't, promotes GPLv3.

There are probably other reasons that don't come to me at the moment.

We would take the same stand on the Hurd vs Linux, if the Hurd were as
usable as Bzr 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 free telephony http://directory.fsf.org/category/tel/

Re: Git mirrors

[Michael Raitza]

>     How does it help the Free Software cause to privilege projects over
>     other Free alternatives putting merit aside just because they have the
>     GNU label sticked on them?

I hope it is clear to us that this is a religious statement in the
sense, that GNU does stand for itself worth to be supported aside what
software comes out of it. So something is good because of its label and
not because of its functions and distributional context.

To put it the other way round. Outweighs the context of distribution and
licensing the functions and useability of a piece of software? Is it
more important who did the work than that it was done?

IMHO. It does only in a limited sense help the Free Software cause
because it only helps GNU. GNU is not _the_ Free Software cause, is it?

Re: Git mirrors

[Miles Bader]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:
> > Though I disagreed at the time, chosing a tool is not a race, but
> > a decision, political as much as anything else. It seems logical
> > to chose the one you favor, and then try to make it better.
>
> Richard made the decision.  I don't see Richard making any
> contributions to Bazaar at all.  I see Eli and Stefan reporting
> bugs, which is indeed a contribution, but hardly *making* it better.
> Emacs is always waiting on Bazaar, waiting on Savannah, waiting,
> waiting, waiting.

That's always been one of the odd things about the whole "bazaar is
GNU" stance:  Although in name it is, it's never really _seemed_ like
part of the GNU project, having been developed independently by -- and
still arguably pretty much controlled by -- Canonical, who's not
exactly a model of GNU-friendly, or even free-software-friendly
behavior (I don't hate Canonical or anything, but I'd definitely keep
a close eye on my wallet when they're in the room...).

My impression was that they saw bazaar was in trouble and losing the
mindshare competition, and offered it to GNU as a sort of last-ditch
measure to try and shore up its popularity and gain a measure of
respectibility by association.

So basically I've always felt like the addition of bazaar to GNU was
more Canonical cynically using GNU's good name for their own ends than
a real donation.

Coupled with the long-standing technical/design problems (it's always
"fixed in the next release / with the new protocol, honestly, for real
this time!") , this makes me quite disinclined to use bazaar.

-Miles

-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: Git mirrors

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Juanma Barranquero <lekktu@gmail.com>,
>  Óscar Fuentes <ofv@wanadoo.es>,
>  Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Thu, 13 Oct 2011 13:55:20 +0900
> 
> Coupled with the long-standing technical/design problems (it's always
> "fixed in the next release / with the new protocol, honestly, for real
> this time!") , this makes me quite disinclined to use bazaar.

FUD.  The protocol is stable since bzr 1.18, which was 2 years ago.

Re: Git mirrors

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
> Cc: Óscar Fuentes <ofv@wanadoo.es>,
>     lekktu@gmail.com,
>     miles@gnu.org,
>     emacs-devel@gnu.org
> Date: Tue, 11 Oct 2011 18:33:46 +0900
> 
> Eli Zaretskii writes:
> 
>  > Why should you expect the Emacs project to behave differently from any
>  > other Free Software project?
> 
> Because most of the projects in the class you have mentioned produce
> free *software*, but their political principles are those of the open
> source movement.  Emacs is different because it *is* a Free Software
> project.

I specifically mentioned Gawk and GDB, which are GNU projects as much
as Emacs.

> One could argue that Emacs should advocate the use of the
> strongest possible "team" of free software tools, rather than being
> biased to the use of GNU-labeled tools.  After all, the project has no
> problem labelling other non-GNU tools (TeX, perl, X11) as "part of the
> GNU System".  But choosing tools on technical capability is clearly
> not the policy of the GNU Project, so the point is moot.

Choosing tools solely on technical capability isn't the policy, true.
But that's not really the point, because I was talking about the
behavior _after_ a decision has been made, not about the decision
itself.  IOW, about "now", and not about "then".

>  > I fail to see how this interpretation can be gleaned from what's been
>  > said here.  Projects that use git as their VCS are not being accused
>  > of being "unfriendly competitors" to the GNU Project, and I, for one,
>  > don't think they are.  So what you say is simply unfair.  I hope
>  > fairness is still a virtue around here.
> 
> Promoting an unusable tool merely because it had the GNU label is most
> definitely unfriendly competition.

Bzr is not unusable, so this argument is simply false.

Re: Git mirrors

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > Because most of the projects in the class you have mentioned produce
 > > free *software*, but their political principles are those of the open
 > > source movement.  Emacs is different because it *is* a Free Software
 > > project.
 > 
 > I specifically mentioned Gawk and GDB, which are GNU projects as much
 > as Emacs.

And therefore should follow the same GNU policies as does Emacs.  No?
So those aren't relevant examples, as the question is "why is the GNU
policy what it is?"

 > Choosing tools solely on technical capability isn't the policy, true.
 > But that's not really the point, because I was talking about the
 > behavior _after_ a decision has been made, not about the decision
 > itself.  IOW, about "now", and not about "then".

That's cheating, of course.  Óscar was talking about both, and
specifically asked why such a policy exists in the first place.  If
you're going to ignore his point, you can't complain that I ignore
yours.

I think he deserves an answer.  It's up to the Emacs leadership whether
that answer is "off-topic" on-list and more responsive off-list, or if
it's worth giving a recap for the several members of the community who
clearly don't understand it on-list.

If you really want these discussions to go away, I think the best
approach is to explain the policy, justify it, put it in the FAQ, and
then shut off future discussion with "off-topic" and a pointer to the
FAQ and an appropriate venue for policy discussion such as
gnu.misc.discuss.

 > > Promoting an unusable tool merely because it had the GNU label is most
 > > definitely unfriendly competition.
 > 
 > Bzr is not unusable, so this argument is simply false.

Eli, if you want to make absolutist arguments like that, start writing
in the propositional calculus.  If you want to continue in English,
then don't be silly.  We all know that your English is good enough
that you can recognize an exaggeration with much truth in it when you
see one.

With regard to the question of "in this case, how much truth is 'much
truth'?", see my response to Juanma.

Re: Git mirrors

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
> Cc: ofv@wanadoo.es,
>     lekktu@gmail.com,
>     emacs-devel@gnu.org,
>     miles@gnu.org
> Date: Wed, 12 Oct 2011 13:55:04 +0900
> 
> Eli Zaretskii writes:
> 
>  > > Because most of the projects in the class you have mentioned produce
>  > > free *software*, but their political principles are those of the open
>  > > source movement.  Emacs is different because it *is* a Free Software
>  > > project.
>  > 
>  > I specifically mentioned Gawk and GDB, which are GNU projects as much
>  > as Emacs.
> 
> And therefore should follow the same GNU policies as does Emacs.  No?
> So those aren't relevant examples, as the question is "why is the GNU
> policy what it is?"

You've changed the subject (and deleted the context that makes that
clear).  I guess this is no longer a rational/serious discussion.

The examples are relevant because these are GNU projects, and so the
are NOT different from Emacs.  If they provide only git, Emacs can
provide just bzr.

>  > Choosing tools solely on technical capability isn't the policy, true.
>  > But that's not really the point, because I was talking about the
>  > behavior _after_ a decision has been made, not about the decision
>  > itself.  IOW, about "now", and not about "then".
> 
> That's cheating, of course.

Are we up to ad hominem yet?

> Óscar was talking about both, and specifically asked why such a
> policy exists in the first place.

No, Óscar was talking about the past.  There's nothing in the present
condition that can justify his views and gripes.  He made a decision
years ago, and he chooses not to revisit that decision given the
changed situation.  That's his prerogative.  But this discussion is
about the situation _now_.  So any arguments about what might have
been true 2 or 3 years ago, but are no longer true now, are not really
relevant.

> If you really want these discussions to go away, I think the best
> approach is to explain the policy, justify it, put it in the FAQ, and
> then shut off future discussion with "off-topic" and a pointer to the
> FAQ and an appropriate venue for policy discussion such as
> gnu.misc.discuss.

The policy was explained many times.  Richard just explained it again.
Nevertheless, I don't expect these discussions to go away, probably
because it's an emotional issue that has very little rational basis.
Witness the fact that this time, no one even tried to claim that bzr
performance is bad.  My conclusion is that technical factors no longer
matter.  It's a religious argument.

>  > > Promoting an unusable tool merely because it had the GNU label is most
>  > > definitely unfriendly competition.
>  > 
>  > Bzr is not unusable, so this argument is simply false.
> 
> Eli, if you want to make absolutist arguments like that, start writing
> in the propositional calculus.  If you want to continue in English,
> then don't be silly.

Are we at ad hominem yet?

> With regard to the question of "in this case, how much truth is 'much
> truth'?", see my response to Juanma.

I see nothing relevant there to this discussion.

Re: Git mirrors

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > That's cheating, of course.
 > 
 > Are we up to ad hominem yet?

Of course not.  Look up "ad hominem".

 > The policy was explained many times.  Richard just explained it
 > again.

No, he didn't.  He stated it, said he thinks this is the right thing,
and he sees no reason to change.  But nobody has presented an argument
in this thread for why choosing GNU over good is good for GNU, or even
why there needs to be Just One GNU-Sanctified application for each
category.  One gets the impression that free software lacking the GNU
label somehow is, uh, "less helpful" to the free software movement
than GNU software is.  But that seems to me to be a rather strange
point of view.  Software doesn't help movements, people do, and the
GNU System can (and does) include any free software it finds useful.
Friendly competition between bzr and git within the GNU System would
be unfortunate (mostly for bzr ;-), but it would (IMO YMMV) make the
GNU System as a whole stronger, just as the presence of both RMail and
Gnus in Emacs makes Emacs stronger.

OTOH, I don't see any real support for the GNU Project in the Bazaar
project; they certainly don't prefer GTK+ over Qt for their GUI, for
example.  AFAICS there are few Emacs users there, and I don't see them
participating here in improving vc.el support for Bazaar.  Etc, etc.
AFAICS the support for GNU is two mentions of the GNU project on the
Bazaar home page.  Maybe they're contributing substantially in other
ways (money to the FSF etc), but nobody has said so, and it's not
obvious to me (and I do follow Bazaar channels).

 > Witness the fact that this time, no one even tried to claim that bzr
 > performance is bad.  My conclusion is that technical factors no longer
 > matter.  It's a religious argument.

That last sentence is true (modulo religious ~ political), and given
that, failure to present technical argument is no evidence of
nonexistence of technical argument.  But now is not the time and here
is not the place....

 > > Eli, if you want to make absolutist arguments like that, start
 > > writing in the propositional calculus.  If you want to continue
 > > in English, then don't be silly.
 > 
 > Are we at ad hominem yet?

No, not even on the same continent.

Re: Git mirrors

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 12 Oct 2011 19:51:11 +0900
> Cc: ofv@wanadoo.es, lekktu@gmail.com, emacs-devel@gnu.org, miles@gnu.org
> 
> Eli Zaretskii writes:
> 
>  > > That's cheating, of course.
>  > 
>  > Are we up to ad hominem yet?
> 
> Of course not.

Yeah, right.

Re: Git mirrors

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Óscar was talking about both, and specifically asked why such a
>> policy exists in the first place.
>
> No, Óscar was talking about the past.  There's nothing in the present
> condition that can justify his views and gripes.

Wrong. I started this after reading that providing a git mirror is not
good for GNU.

[snip]

> The policy was explained many times.  Richard just explained it again.

Where? Is this what you are talking about? :

Richard Stallman <rms@gnu.org> writes:

>     I was restraining myself from making this question since long time ago:
>     is GNU a competing project against other *Free* projects?
>
> Competition is common in the free software world.
> When a GNU package competes with a non-GNU package,
> but we should promote other GNU projects first.

Even if I could parse that, it doesn't seem an explanation, but the
statement of a policy.

[snip]

Re: Git mirrors

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 12 Oct 2011 16:01:44 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Óscar was talking about both, and specifically asked why such a
> >> policy exists in the first place.
> >
> > No, Óscar was talking about the past.  There's nothing in the present
> > condition that can justify his views and gripes.
> 
> Wrong. I started this after reading that providing a git mirror is not
> good for GNU.

No one said if was "not good".  Glenn said it "would not benefit" the
GNU project.  My translation is: "will not make the GNU project better
than it was before".

> > The policy was explained many times.  Richard just explained it again.
> 
> Where? Is this what you are talking about? :

Yes, that's the latest installment.

> Richard Stallman <rms@gnu.org> writes:
> 
> >     I was restraining myself from making this question since long time ago:
> >     is GNU a competing project against other *Free* projects?
> >
> > Competition is common in the free software world.
> > When a GNU package competes with a non-GNU package,
> > but we should promote other GNU projects first.
> 
> Even if I could parse that, it doesn't seem an explanation, but the
> statement of a policy.

Feel free to ask for details.  It's clear enough for me, but YMMV.

Re: Git mirrors

[Richard Stallman]

     > I specifically mentioned Gawk and GDB, which are GNU projects as much
     > as Emacs.

    And therefore should follow the same GNU policies as does Emacs.  No?

They should.  They must have adopted some other platform before I
noticed, and making them change now would be difficult, but I wish
they would.

-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Git mirrors

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> The decision on Bzr was political, not technical
>
> Yes, it was.  So was the decision to develop GNU Emacs, GCC, and the
> whole GNU Project.  And your point is?

You are comparing apples to oranges. Emacs and GCC came into being
because there was no available options that were Free and
cooperative. Or else a decission to create a flagship for Free Software
was taken. That does not fit the bzr case at all.

>> and now objections are made to adding support for other Free tools
>> as a service to those contributors that consider them more
>> convenient.
>
> No, there are no objections to that.  You (or anyone else) are free to
> set out to make that happen, whether on Savannah or elsewhere.

That's not how do I interpret this reaction:

<quote>

    > I think it would benefit the GNU Emacs project, the Emacs developers and
    > maintainers, and the Emacs community as a whole if there was an official
    > read-only Git mirror of the Emacs repository that was updated with every
    > Bazaar push.

    I just want to make the point that since Bazaar is a GNU project, IMO
    this would not benefit the GNU project as a whole. (I'm not saying don't
    do it, just making a point.)

That's my response too.

</quote>

> Objections _are_ made to force the Emacs project to do this work for
> you,

No. There are people who are volunteering:

<quote>

> Trying to be constructive about this, this would be helpful, but presumably
> a fully automatic sync is not possible, or someone would have done it by
> now.

I have my own fully-automated sync happening here on my own machine, using
git-bzr and bzr-fast-import, so I can't imagine it would be any harder for a
server to do.

> If someone can do it, please work to get it done on Savannah so that we
> never have to have this discussion again.

Give me ssh access and I'll do it.

</quote>

> when in fact the Emacs project already provides a reasonable
> solution for distributed development and contribution to the project.

"Reasonable" is your opinion. Certainly it works, but it is a PITA to
use for some of us.

> Let me turn the table and ask you: are you aware of any significant
> number of projects that use git and provide a bzr gateway for those
> who want that?  I have yet to see such a project.

I was involved on projects that were perfectly fine with providing bzr
access at the request of users. And here "users" means "Óscar". Then I
switched to git and nobody asked for bzr support since.

But are you suggesting that git users are reluctant to provide bzr
access to the projects were they participate? Is this about rejecting
the setup of a working git mirror for Emacs because some project out
there rejected to setup a bzr mirror? Please let's drop this argument.

[snip]

>> What I'm saying is that that does not send a friendly signal to
>> other Free Software projects and representing GNU as an unfriendly
>> competitor of other Free tools harms the cause of Free Software.
>
> I fail to see how this interpretation can be gleaned from what's been
> said here.  Projects that use git as their VCS are not being accused
> of being "unfriendly competitors" to the GNU Project, and I, for one,
> don't think they are.  So what you say is simply unfair.  I hope
> fairness is still a virtue around here.

You are completely dismissing history. I'm sure you can recall how bzr
was chosen and the whole saga until it was operational. When the
decission of using bzr was made, it was a niche tool with known heavy
performance problems that required more than a year to fix while
mercurial and git were perfectly fit, with a git mirror of the CVS repo
in working state. The message to Free Software developers is clear:
"either bow to GNU, or your work will be ignored by us, no matter how
excellent it is."  And this is where I ask: is GNU an end on itself or a
means to promote Free Software? Is it about the success of GNU or the
success of Free Software?

Re: Git mirrors

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 11 Oct 2011 14:56:26 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The decision on Bzr was political, not technical
> >
> > Yes, it was.  So was the decision to develop GNU Emacs, GCC, and the
> > whole GNU Project.  And your point is?
> 
> You are comparing apples to oranges. Emacs and GCC came into being
> because there was no available options that were Free and
> cooperative. Or else a decission to create a flagship for Free Software
> was taken. That does not fit the bzr case at all.

Sorry, I don't see the difference.  My point is that political
decisions are not necessarily bogus just _because_ they are political.

>     > I think it would benefit the GNU Emacs project, the Emacs developers and
>     > maintainers, and the Emacs community as a whole if there was an official
>     > read-only Git mirror of the Emacs repository that was updated with every
>     > Bazaar push.
> 
>     I just want to make the point that since Bazaar is a GNU project, IMO
>     this would not benefit the GNU project as a whole. (I'm not saying don't
>     do it, just making a point.)
> 
> That's my response too.

These are not objections.  Objection would be to say "no, don't do
this because I object".  Glenn said explicitly "I'm not saying don't
do it".

> > Objections _are_ made to force the Emacs project to do this work for
> > you,
> 
> No. There are people who are volunteering:
> 
> <quote>
> 
> > Trying to be constructive about this, this would be helpful, but presumably
> > a fully automatic sync is not possible, or someone would have done it by
> > now.

Then there's nothing to argue about, is there?  You don't actually
need to force people to agree with you, do you?  It is good enough to
have a reliable git mirror, isn't it?

Or is this a "political" dispute?

> I have my own fully-automated sync happening here on my own machine, using
> git-bzr and bzr-fast-import, so I can't imagine it would be any harder for a
> server to do.

I guess volunteers still have to do something, then.

> > If someone can do it, please work to get it done on Savannah so that we
> > never have to have this discussion again.
> 
> Give me ssh access and I'll do it.

Ask someone who can do it, like savannah admins.  I don't have such an
access myself.

> > when in fact the Emacs project already provides a reasonable
> > solution for distributed development and contribution to the project.
> 
> "Reasonable" is your opinion. Certainly it works, but it is a PITA to
> use for some of us.

It is PITA for me to use git, but I don't run back crying to the
projects who use it, and don't spread FUD about git, which I consider
a very good tool.

> > Let me turn the table and ask you: are you aware of any significant
> > number of projects that use git and provide a bzr gateway for those
> > who want that?  I have yet to see such a project.
> 
> I was involved on projects that were perfectly fine with providing bzr
> access at the request of users.

So we have one such project.  Or rather _had_ one such project.  Not a
lot to go by, I'd say.

> Please let's drop this argument.

Feel free.

> >> What I'm saying is that that does not send a friendly signal to
> >> other Free Software projects and representing GNU as an unfriendly
> >> competitor of other Free tools harms the cause of Free Software.
> >
> > I fail to see how this interpretation can be gleaned from what's been
> > said here.  Projects that use git as their VCS are not being accused
> > of being "unfriendly competitors" to the GNU Project, and I, for one,
> > don't think they are.  So what you say is simply unfair.  I hope
> > fairness is still a virtue around here.
> 
> You are completely dismissing history.

I'm not interested in history in this thread.  This thread is about
using the Emacs repository _now_.  Whatever problems were in the past,
they cannot possibly affect the efficiency of accessing the repository
from now on.

Re: Git mirrors

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> The decision on Bzr was political, not technical
>> >
>> > Yes, it was.  So was the decision to develop GNU Emacs, GCC, and the
>> > whole GNU Project.  And your point is?
>> 
>> You are comparing apples to oranges. Emacs and GCC came into being
>> because there was no available options that were Free and
>> cooperative. Or else a decission to create a flagship for Free Software
>> was taken. That does not fit the bzr case at all.
>
> Sorry, I don't see the difference.  My point is that political
> decisions are not necessarily bogus just _because_ they are political.

And this whole subthread is about my impression that the policy that
chose bzr over its competitors is, possibly, damaging for Free
Software. That's all. I'm not proposing to ditch bzr, nor advocating
git, nor asking others to do work for me. All that is your strawman
argument. You go to the point of arguing with me about quotes that I
included (and marked as such) on my previous message, as if I were the
author of such quotes. Once you calm down to the point of understanding
what I actually wrote, I'll be happy to discuss the first point
mentioned on this paragraph, which is what I care about. In private,
please, as we already created enough noise with this.

[snip]

Re: Git mirrors

[Richard Stallman]

    And this whole subthread is about my impression that the policy that
    chose bzr over its competitors is, possibly, damaging for Free
    Software.

I doubt it, and I'm not impressed.


-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Git mirrors

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> I have my own fully-automated sync happening here on my own machine, using
> git-bzr and bzr-fast-import, so I can't imagine it would be any harder for a
> server to do.
>
>> If someone can do it, please work to get it done on Savannah so that we
>> never have to have this discussion again.
>
> Give me ssh access and I'll do it.

Hmm, since you're already part of the emacs project, (presumably),
can't you already push to the savannah git repo just by registering
your ssh key there?

-miles

-- 
Religion, n. A daughter of Hope and Fear, explaining to Ignorance the nature
of the Unknowable.

Re: Git mirrors

[Richard Stallman]

    I was restraining myself from making this question since long time ago:
    is GNU a competing project against other *Free* projects?

Competition is common in the free software world.
When a GNU package competes with a non-GNU package,
but we should promote other GNU projects first.

-- 
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 free telephony http://directory.fsf.org/category/tel/

What about Python? (was: Git mirrors)

[Barry Fishman]

On 2011-10-11 08:34:35 EDT, Richard Stallman wrote:
> Competition is common in the free software world.
> When a GNU package competes with a non-GNU package,
> but we should promote other GNU projects first.

Bazaar is written in Python and requires A Python-2 environment to be
installed on a system using Bazaar.  Doesn't this make Python a GNU
package?  At least it is a GNU required package.

This mean that the success of Python is now a requirement of the GNU
project.

Does this mean that GNU should promote Python over other competing
languages like Perl, Ruby and Guile?

-- 
Barry Fishman

Re: What about Python? (was: Git mirrors)

[Richard Stallman]

    Bazaar is written in Python and requires A Python-2 environment to be
    installed on a system using Bazaar.  Doesn't this make Python a GNU
    package?

No.  See gnu.org/categories.html for what it means to be a GNU
package.

	      At least it is a GNU required package.

If you define "GNU required package" as any package needed
to run some GNU package, then Python would be one.
But that is not a concept we 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 free telephony http://directory.fsf.org/category/tel/

Re: Git mirrors

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Mon, 10 Oct 2011 17:02:33 -0500
> 
> On Sat, 08 Oct 2011 04:50:07 -0400 Richard Stallman <rms@gnu.org> wrote: 
> 
> RS>     I just want to make the point that since Bazaar is a GNU project, IMO
> RS>     this would not benefit the GNU project as a whole. (I'm not saying don't
> RS>     do it, just making a point.)
> 
> RS> That's my response too.
> 
> Are you simply ignoring Glenn's last sentence?
> 
> Why does Savannah offer Git hosting if you feel even providing a
> read-only Git mirror harms the GNU project?

Please be fair: Glenn didn't say "harm", he said "not benefit".  These
are not the same.

> Is Emacs a tool or a weapon?

Sounds like you are the only one with a weapon here ;-)

Re: Git mirrors

[Ted Zlatanov]

On Tue, 11 Oct 2011 06:08:33 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Mon, 10 Oct 2011 17:02:33 -0500
>> 
>> On Sat, 08 Oct 2011 04:50:07 -0400 Richard Stallman <rms@gnu.org> wrote: 
>> 
RS> I just want to make the point that since Bazaar is a GNU project, IMO
RS> this would not benefit the GNU project as a whole. (I'm not saying don't
RS> do it, just making a point.)
>> 
RS> That's my response too.
>> 
>> Are you simply ignoring Glenn's last sentence?
>> 
>> Why does Savannah offer Git hosting if you feel even providing a
>> read-only Git mirror harms the GNU project?

EZ> Please be fair: Glenn didn't say "harm", he said "not benefit".  These
EZ> are not the same.

OK, I'll just ask why Savannah offers Git hosting for GNU projects.

Ted

Re: Git mirrors

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> OK, I'll just ask why Savannah offers Git hosting for GNU projects.

I have no idea what all y'all are arguing about.  I asked for an
up-to-date git mirror to be set up, and that's apparently being done.

So this discussion is redundant.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Git mirrors

[Stefan Monnier]

> I have no idea what all y'all are arguing about.  I asked for an
> up-to-date git mirror to be set up, and that's apparently being done.

Indeed, tho I haven't heard back from John recently.  BTW, when this is
setup, it would be great to add the mirroring script into the
`admin' dir.


        Stefan

Re: Git mirrors

[John Wiegley]

>>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Indeed, tho I haven't heard back from John recently.  BTW, when this is
> setup, it would be great to add the mirroring script into the `admin' dir.

Stefan, I'm still waiting on an answer to this question:

  Stefan, how I do I clone Savannah's Git mirror using SSH?  Nothing that I'm
  trying has worked:
  
    git clone johnw@git.savannah.gnu.org:emacs.git
    git clone git+ssh://johnw@git.savannah.gnu.org/emacs.git

I've got the mirroring process running hourly now, it's just lacking the
"push" bit.

John

Re: Git mirrors

[Óscar Fuentes]

John Wiegley <jwiegley@gmail.com> writes:

> Stefan, I'm still waiting on an answer to this question:
>
>   Stefan, how I do I clone Savannah's Git mirror using SSH?  Nothing that I'm
>   trying has worked:
>   
>     git clone johnw@git.savannah.gnu.org:emacs.git
>     git clone git+ssh://johnw@git.savannah.gnu.org/emacs.git
>
> I've got the mirroring process running hourly now, it's just lacking the
> "push" bit.

This is a question for the Savannah admins or some Emacs hacker who has
actual experience with those operarions, such as Andreas Schwab, CCed.

Re: Git mirrors

[John Wiegley]

>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:

>> I've got the mirroring process running hourly now, it's just lacking the
>> "push" bit.

> This is a question for the Savannah admins or some Emacs hacker who has
> actual experience with those operarions, such as Andreas Schwab, CCed.

The mirror is running now and mirroring up to Savannah.  Whom do I ask to
disable the current mirroring code, so we never step on each other?

Also, is there a way to get Bazaar on Savannah to use curl to frob a URL
whenever a commit is made?  If so, I could change the mirroring scheme to be
by-commit, rather than hourly.

Thanks,
  John

Re: Git mirrors

[Stefan Monnier]

> The mirror is running now and mirroring up to Savannah.  Whom do I ask to
> disable the current mirroring code, so we never step on each other?

I think Jim Meyering was doing the mirroring.
I'm not sure what kind of "step on each other" risk there is.
If you both use "git push", there shouldn't be any problem, right?
I'm asking because I think it'd be good to make sure that anyone can
pick up and update the mirror if your setup fails/disappears/... (this
has happened with Jim's mirroring, for example, tho of course that's
mostly because it was hand-updated).

> Also, is there a way to get Bazaar on Savannah to use curl to frob a URL
> whenever a commit is made?  If so, I could change the mirroring scheme to be
> by-commit, rather than hourly.

I don't think there's much chance of that happening.  Even savannah's
own "send commits to mailing-list" uses the "bzr-hookless-mail" so as to
avoid such a thing.
I don't think an hourly backup is a significant problem.


        Stefan

Re: Git mirrors

[John Wiegley]

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

>> The mirror is running now and mirroring up to Savannah.  Whom do I ask to
>> disable the current mirroring code, so we never step on each other?

> I think Jim Meyering was doing the mirroring.  I'm not sure what kind of
> "step on each other" risk there is.  If you both use "git push", there
> shouldn't be any problem, right?  I'm asking because I think it'd be good to
> make sure that anyone can pick up and update the mirror if your setup
> fails/disappears/... (this has happened with Jim's mirroring, for example,
> tho of course that's mostly because it was hand-updated).

I'm using git push --mirror, which deleted 6 old branches, so clearly Jim is
doing something slightly different from me.  One form of "step on each other"
would be that he keeps pushing those branches, and I keep deleting them.

>> Also, is there a way to get Bazaar on Savannah to use curl to frob a URL
>> whenever a commit is made?  If so, I could change the mirroring scheme to
>> be by-commit, rather than hourly.

> I don't think there's much chance of that happening.  Even savannah's own
> "send commits to mailing-list" uses the "bzr-hookless-mail" so as to avoid
> such a thing.  I don't think an hourly backup is a significant problem.

OK.

John

Re: Git mirrors

[Andreas Schwab]

John Wiegley <jwiegley@gmail.com> writes:

> I'm using git push --mirror, which deleted 6 old branches

You need to fix that.

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: Git mirrors

[Dave Abrahams]

on Wed Oct 12 2011, Andreas Schwab <schwab-AT-linux-m68k.org> wrote:

> John Wiegley <jwiegley@gmail.com> writes:
>
>> I'm using git push --mirror, which deleted 6 old branches
>
> You need to fix that.

Are you saying those branches need to come back, or...?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Git mirrors

[John Wiegley]

>>>>> Andreas Schwab <schwab@linux-m68k.org> writes:

>> I'm using git push --mirror, which deleted 6 old branches

> You need to fix that.

It deleted those branches because they no longer exist on the Bzr side.  There
is no way to "fix" what --mirror does, unless I stop mirroring the branch
structure and only copy (which means cruft may accumulate on the Git side).

John

Re: Git mirrors

[Andreas Schwab]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>>> I'm using git push --mirror, which deleted 6 old branches
>
>> You need to fix that.
>
> It deleted those branches because they no longer exist on the Bzr
> side.

??? None of the branches disappeared.

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: Git mirrors

[Óscar Fuentes]

John Wiegley <jwiegley@gmail.com> writes:

> The mirror is running now and mirroring up to Savannah.

Many thanks for doing this.

> Whom do I ask to disable the current mirroring code, so we never step
> on each other?

AFAIK, the only one keeping the savannah git mirror up to date is
Andreas Schwab and he is doing that manually. I'm not sure what's the
actual process he is using, but if it is fast-import/fast-export the
worst thing that could happen is a failed push because the other part
pushed first. In that case a pull should fix things. But he has the
authoritative word on this.

> Also, is there a way to get Bazaar on Savannah to use curl to frob a URL
> whenever a commit is made?  If so, I could change the mirroring scheme to be
> by-commit, rather than hourly.

There are already commit hooks into place (for feeding the emacs-diffs
mailing list, for instance.) What you ask for shouldn't be too
complicated in comparison, but most likely only the savannah admins or
the project owners are authorized for doing that.

Re: Git mirrors

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

[snip]

>> Whom do I ask to disable the current mirroring code, so we never step
>> on each other?
>
> AFAIK, the only one keeping the savannah git mirror up to date is
> Andreas Schwab and he is doing that manually. I'm not sure what's the
> actual process he is using, but if it is fast-import/fast-export the
> worst thing that could happen is a failed push because the other part
> pushed first. In that case a pull should fix things. But he has the
> authoritative word on this.

Well, as fast-export/fast-import should produce identical output
anytime, anyplace, if someone pushes before you shouldn't be any problem
at all, because the git repo at savannah already has the revisions you
are trying to push, so the operation would simply update your
remotes/origin/* pointers.

Modulo bugs :-/

>> Also, is there a way to get Bazaar on Savannah to use curl to frob a URL
>> whenever a commit is made?  If so, I could change the mirroring scheme to be
>> by-commit, rather than hourly.
>
> There are already commit hooks into place (for feeding the emacs-diffs
> mailing list, for instance.) What you ask for shouldn't be too
> complicated in comparison, but most likely only the savannah admins or
> the project owners are authorized for doing that.

After reading Stefan's reply it seems that it is not so easy. An hourly
refresh is very good, although mirroring by-commit would be superb for
the occasional cases where you report a bug, a hacker commits a quick
fix and asks you to test it, everything on a fast mail-chat. Maybe you
can react to messages sent to emacs-diffs? In any case keep in mind that
some hackers pushes several revisions on one batch: maybe it is not a
good idea resource-wise to fire the export/import ten times on a row
when the first one grabbed all the new revisions :-)

Re: Git mirrors

[Richard Stallman]

This discussion about a git mirror on Savannah feels to me like an
attempt to unofficially replace bzr with git as the principle platform
for Emacs development.

That is going in the wrong direction.

-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Git mirrors

[John Wiegley]

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

> This discussion about a git mirror on Savannah feels to me like an attempt
> to unofficially replace bzr with git as the principle platform for Emacs
> development.

> That is going in the wrong direction.

What we are really trying to do is engage the Emacs community to spend more
time on Emacs rather than fighting version control.  For many, the "path of
least resistance" is to provide commits in a format they can most easily
consume, rather than mandating that all use a single system to satisfy a
political goal which may or may not concern them.

In the end, I think increasing the pool of Emacs developers, the speed of
Emacs development, the amount of testing and bug fixing that gets done, will
serve the FSF's overall agenda more than trying to garner public support for
Bazaar through a single project.

John

Re: Git mirrors

[Karl Fogel]

John Wiegley <jwiegley@gmail.com> writes:
>What we are really trying to do is engage the Emacs community to spend more
>time on Emacs rather than fighting version control.  For many, the "path of
>least resistance" is to provide commits in a format they can most easily
>consume, rather than mandating that all use a single system to satisfy a
>political goal which may or may not concern them.
>
>In the end, I think increasing the pool of Emacs developers, the speed of
>Emacs development, the amount of testing and bug fixing that gets done, will
>serve the FSF's overall agenda more than trying to garner public support for
>Bazaar through a single project.

+1

It is *because* I support free software that I wish Emacs would switch
to Git on Savannah.  Doing so would be better for the cause.

That's no slur on Bazaar.  It's just that Savannah clearly does not have
have the resources to support many different version control systems
well -- and as a result, we're not really helping Bazaar anyway.

If the goal is to support another GNU project, our switch to Bzr did not
serve that goal.  Our difficulties switching to it have become well
known and have been cited *by other projects* as an argument against
switching to Bazaar themselves.  We're not doing Bazaar any favors by
continuing to use it poorly and then complaining about it amongst
ourselves in publicly-archived forums!

(Sorry, no, I'm not going to spend time digging up the references unless
there's a serious chance that doing so will cause GNU Emacs development
to switch to Git or some other system that the majority of this group
actually prefers.)

The idea that we are helping either ourselves or a fellow GNU project
here should be treated as merely a hypothesis until there is actual
evidence of it.

-Karl

Re: Git mirrors

[Stephen J. Turnbull]

Karl Fogel writes:

 > (Sorry, no, I'm not going to spend time digging up the references unless
 > there's a serious chance that doing so will cause GNU Emacs development
 > to switch to Git or some other system that the majority of this group
 > actually prefers.)

Realistically, there won't be any such majority.  Bazaar today is
perhaps the best dVCS for supporting the traditional Emacs workflow,
and people who want to evolve their own workflows can use either non-
default or experimental bzr plugins, or $dVCS mirrors with levels of
effort that are hardly prohibitive.

 > The idea that we are helping either ourselves or a fellow GNU project
 > here should be treated as merely a hypothesis until there is actual
 > evidence of it.

Sorry, Karl, although as a social scientist *I* agree with you, *GNU*
is a social movement.  Action *should* be taken, and Richard has
decided that he is sure enough of this effect that he has instituted
the "Prefer GNU over non-GNU" policy.  You really can't use "treat as
an hypothesis until proof is available" here; this is a "you bet your
movement" decision, and "deciding not to decide" is a negative
decision because it means inaction.

I really think the Bazaar case should get a post-mortem review,
though.  Comparing "What it means for a program to be a GNU package"
in <URL:http://www.gnu.org/help/evaluation.html> with the actual
behavior of the Bazaar project (which should not be confused with the
aspirations of some of its developers) and its parent corporation is
discouraging.  Pretty much every point in "evaluation.html" is
violated (admittedly mostly in petty ways) by the Bazaar project,
starting with licensing (use of GPL v2 and an allegedly obnoxious
contributor agreement).  Although the software is free, in practice
the Bazaar project is a wholly-owned subsidiary of a corporation that
has used proprietary software or ASP/SaaS based on undistributed
software on a large scale in its products (eg, Launchpad itself,
proprietary at its launch but since freed, I believe).

If the "Use GNU" policy is to make sense, I think the criterion
proposed by Vijay Lakshminarayanan should be applied:

    The reason to support GNU projects over others is that it is the
    stated goal of GNU that all distributed software should be Free
    ....  To this end, any software project that shares the same goals
    will be supported.

(Note: the omitted text was "and copylefted by law", which AFAIK is a
non-goal.  Use of copyleft is a means to the goal of software freedom,
and will be impossible when copyright in software is abolished, which
AFAIK still is a particular goal in support of software freedom.)

I don't think that Bazaar fits Vijay's description well at all.  It is
a commercial enterprise in support of the Launchpad product and
Canonical's consulting business first and foremost, and software
freedom hardly ever enters the discussion -- rather it is quite taken
for granted.  Support for proprietary platforms is an explicit goal of
the project.  In general, the project ethos seems to be closer to open
source than to free software to me.  Quite a contrast to the GNU Arch
project (which although a GNU package since 2003 and quite usable even
then, was never seriously considered for the kind of preference Bazaar
got)!

I don't think either the GNU package status of Bazaar or Emacs's use
of it should be changed.  Rather, based on what I've seen so far I
think that it would be wise if (1) the GNU Project required a bit more
evidence of devotion to software freedom and to GNU than merely adding
the GNU brand to the home page and occasionally substituting
"GNU/Linux" for "Linux" in documentation before granting "GNU package"
status, (2) Bazaar (in particular) were encouraged to devote on-going
effort to working for software freedom (as opposed to running a
business based on free software), (3) the GNU Project would devote
more effort to getting all projects to do the same, (4) Emacs (as a
flagship GNU project) would exercise leadership in the above.  Thus
the suggestion for a review of this case.

Of course, since I actively disagree with the policy in the first
place, I'm not going to do any of the above myself.  I'm just
suggesting a path to improvements in the implementation of a policy
based on my understanding of the goals of its proponents. ;-)

Nobody-expects-the-Loyal-Opposition-ly y'rs,

Re: Git mirrors

[Bastien]

Why don't we run a poll to ask GNU Emacs devs what dVCS they
would like to use for GNU Emacs development?

-- 
 Bastien

Re: Git mirrors

[Richard Stallman]

    Why don't we run a poll to ask GNU Emacs devs what dVCS they
    would like to use for GNU Emacs development?

Because the issue goes beyond the question of what is convenient for
Emacs development at the present time.

-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Git mirrors

[Bastien]

Richard Stallman <rms@gnu.org> writes:

>     Why don't we run a poll to ask GNU Emacs devs what dVCS they
>     would like to use for GNU Emacs development?
>
> Because the issue goes beyond the question of what is convenient for
> Emacs development at the present time.

John's point is about both conveniency and how using bzr is not the
best way to support FSF's goals.  Karl's point goes into more details 
about the latter issue.  FWIW, I agree with both John and Karl.

Polling Emacs developers about what dVCS they want to use is not about
conveniency alone, it is about all these issues, political ones
included.

But seeing very little support for this idea, I guess there is something
wrong with it.  Thanks to John's work things are going in the right
direction anyway.

-- 
 Bastien

Re: Git mirrors

[Vijay Lakshminarayanan]

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

[snip]

> If the "Use GNU" policy is to make sense, I think the criterion
> proposed by Vijay Lakshminarayanan should be applied:
>
>     The reason to support GNU projects over others is that it is the
>     stated goal of GNU that all distributed software should be Free
>     ....  To this end, any software project that shares the same goals
>     will be supported.
>
> (Note: the omitted text was "and copylefted by law", which AFAIK is a
> non-goal.  Use of copyleft is a means to the goal of software freedom,
> and will be impossible when copyright in software is abolished, which
> AFAIK still is a particular goal in support of software freedom.)

I don't think the FSF wants the elimination of copyright and I didn't
intend that in my earlier post.  My guess is that the FSF would welcome
a law that said all software should be released with a copyleft license.

[snip]

-- 
Cheers
~vijay

Gnus should be more complicated.

Re: Git mirrors

[Stephen J. Turnbull]

Vijay Lakshminarayanan writes:

 > I don't think the FSF wants the elimination of copyright

I recommend to you an essay by Richard Stallman, entitled "Why
Software Should Not have Owners."  You can find it in Richard's book
/Free Software Free Society/ from the GNU Press, and it's probably
available somewhere under http://www.gnu.org/philosophy/.  As far as
this point goes, you only need to read the title and the first two or
three sentences.

Re: Git mirrors

[Vijay Lakshminarayanan]

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

> Vijay Lakshminarayanan writes:
>
>  > I don't think the FSF wants the elimination of copyright
>
> I recommend to you an essay by Richard Stallman, entitled "Why
> Software Should Not have Owners."  You can find it in Richard's book
> /Free Software Free Society/ from the GNU Press, and it's probably
> available somewhere under http://www.gnu.org/philosophy/.  As far as
> this point goes, you only need to read the title and the first two or
> three sentences.

You're right.  RMS's essay at
http://www.gnu.org/philosophy/pirate-party.html indicates a preference
for a reduction term of software copyright rather than elimination all
together.

-- 
Cheers
~vijay

Gnus should be more complicated.

Re: Git mirrors

[Richard Stallman]

    I recommend to you an essay by Richard Stallman, entitled "Why
    Software Should Not have Owners."

I see I need to correct that essay to reflect the fact that copyright
is only one of the mechanisms used to make software proprietary.
And not the principal mechanism.

-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Git mirrors

[Richard Stallman]

    I don't think the FSF wants the elimination of copyright and I didn't
    intend that in my earlier post.  My guess is that the FSF would welcome
    a law that said all software should be released with a copyleft license.

The FSF would welcome a legal requirement to make all software free
but does not advocate one now.  It would be too drastic a change
for the current situation.

-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Git mirrors

[Barry Warsaw]

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

On Oct 13, 2011, at 02:09 PM, Stephen J. Turnbull wrote:

>Although the software is free, in practice the Bazaar project is a
>wholly-owned subsidiary of a corporation that has used proprietary software
>or ASP/SaaS based on undistributed software on a large scale in its products
>(eg, Launchpad itself, proprietary at its launch but since freed, I believe).

Launchpad is licensed under the AGPL, so yes, it is free software.

>If the "Use GNU" policy is to make sense, I think the criterion
>proposed by Vijay Lakshminarayanan should be applied:
>
>    The reason to support GNU projects over others is that it is the
>    stated goal of GNU that all distributed software should be Free
>    ....  To this end, any software project that shares the same goals
>    will be supported.
>
>I don't think that Bazaar fits Vijay's description well at all.  It is
>a commercial enterprise in support of the Launchpad product and
>Canonical's consulting business first and foremost, and software
>freedom hardly ever enters the discussion -- rather it is quite taken
>for granted.

Both Launchpad and Bazaar are free software.  Both provide significant support
for free software, the former by hosting many free software projects, and the
latter by being the native dVCS for many free software projects.  Developers
of both systems actively care about the needs of free software developers, and
like most conscientious, honorable, dedicated, devoted, hard-working, and
overworked free software developers, would do what they can within the
resources they have to improve the support for other free software.

-Barry

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

Re: Git mirrors

[Stephen J. Turnbull]

Barry Warsaw writes:

 > Both Launchpad and Bazaar are free software.  Both provide
 > significant support for free software, the former by hosting many
 > free software projects, and the latter by being the native dVCS for
 > many free software projects.  Developers of both systems actively
 > care about the needs of free software developers, and like most
 > conscientious, honorable, dedicated, devoted, hard-working, and
 > overworked free software developers, would do what they can within
 > the resources they have to improve the support for other free
 > software.

s/free/open source/ and you will have a semantically identical passage
that could have been written by Eric S. Raymond.  But all that is
secondary for the Free Software movement, which is why there is an
open source movement separate from the free software movement.

Re: Git mirrors

[Ted Zlatanov]

On Wed, 12 Oct 2011 17:54:01 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS> This discussion about a git mirror on Savannah feels to me like an
RS> attempt to unofficially replace bzr with git as the principle platform
RS> for Emacs development.

It's not.  The thread topic, in fact, is "mirrors" and no more.

Ted

Re: Git mirrors

[John Wiegley]

>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:

> AFAIK, the only one keeping the savannah git mirror up to date is Andreas
> Schwab and he is doing that manually. I'm not sure what's the actual process
> he is using, but if it is fast-import/fast-export the worst thing that could
> happen is a failed push because the other part pushed first. In that case a
> pull should fix things. But he has the authoritative word on this.

Sure enough, I'm stepping on whoever else is running an automated mirroring
process.  Just about every hour I'm re-deleting branches that they are
re-pushing:

,----
| ======================================================================
| Wed Oct 12 18:00:01 CDT 2011
| ======================================================================
| receiving incremental file list
| 
| sent 357 bytes  received 20797 bytes  475.37 bytes/sec
| total size is 376714147  speedup is 17808.18
| To savannah:/srv/git/emacs.git
|  - [deleted]         old-branches/cedet-branch
|  - [deleted]         old-branches/emacs-unicode
|  - [deleted]         old-branches/gerd_defvaralias
|  - [deleted]         old-branches/gnus-5_10-branch
|  - [deleted]         old-branches/multi-tty
|  - [deleted]         old-branches/pending
|  - [deleted]         old-branches/rmail-mbox-branch
|  - [deleted]         other-branches/gerd_0001
|  - [deleted]         other-branches/gerd_int
|  - [deleted]         other-branches/miles-orphaned-changes
|  - [deleted]         other-branches/thomas-posix1996
|  * [new branch]      tmp -> tmp
`----

Who do I talk to so that they disable their mirror, or at least refine it?
Below is the script I'm now using.  It relies upon a Python script, also
attached.

John

------------------------------------------------------------------------
#!/bin/bash

# Many thanks to Andreas Schwab <schwab@linux-m68k.org> for this script.  It
# is currently maintained by John Wiegley <johnw@newartisans.com>.

test last-sync-start -nt last-sync-ready || touch -r last-sync-start last-sync
touch last-sync-start

echo ======================================================================
date
echo ======================================================================

rsync -av --del --delete-excluded \
    --exclude=obsolete_packs \
    --exclude=lock/ \
    bzr.sv.gnu.org::bzr/emacs/ emacs.bzr/

dc emacs.bzr
find * -path '*/.bzr/branch/last-revision' | while read r; do
  test $r -ot ../last-sync && continue
  b=${r%/.bzr/*}
  b2=$b
  test $b = trunk && b2=master
  test $b = master && b2=bzr/master
  echo $b
  bzr fast-export --plain --marks=../bzr-marks -b $b2 $b | (
    cd ../emacs.git
    git fast-import --quiet --export-marks=../git-marks --import-marks=../git-marks
  )
done

dc ../emacs.git
git push --mirror savannah:/srv/git/emacs.git

cd ..
bin/correlate | gzip -c > commit-map.txt.gz

touch last-sync-ready

exit 0

### emacs-mirror.sh ends here

------------------------------------------------------------------------

#!/usr/bin/env python

# This is bin/correlate

import re
import os

def load_marks(path, inserter):
    marks = open(path)
    for line in marks.readlines():
        match = re.match(':([0-9]+) (.+)', line)
        assert match
        ident, info = match.groups()
        inserter(table, ident, info)

    marks.close()

def insert_at(table, key, value, pos):
    if key not in table:
        table[key] = [None, None]
    table[key][pos] = value

table = {}

load_marks('bzr-marks',
           lambda table, ident, info: insert_at(table, ident, info, 0))
load_marks('git-marks',
           lambda table, ident, info: insert_at(table, ident, info, 1))

for key in table:
    print table[key][0], table[key][1]

Re: Git mirrors

[Andreas Schwab]

John Wiegley <jwiegley@gmail.com> writes:

> Just about every hour I'm re-deleting branches that they are
> re-pushing:

You need to fix that.

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: Git mirrors

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> Just about every hour I'm re-deleting branches that they are
>> re-pushing:
>
> You need to fix that.

It would probably be helpful if you explained at slightly more length
how this should be fixed.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Git mirrors

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>>> Just about every hour I'm re-deleting branches that they are
>>> re-pushing:
>>
>> You need to fix that.
>
> It would probably be helpful if you explained at slightly more length
> how this should be fixed.

Just don't delete them.  The branches exist.

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: Git mirrors

[Stefan Monnier]

> | ======================================================================
> | Wed Oct 12 18:00:01 CDT 2011
> | ======================================================================
> | receiving incremental file list
> | 
> | sent 357 bytes  received 20797 bytes  475.37 bytes/sec
> | total size is 376714147  speedup is 17808.18
> | To savannah:/srv/git/emacs.git
> |  - [deleted]         old-branches/cedet-branch
> |  - [deleted]         old-branches/emacs-unicode
> |  - [deleted]         old-branches/gerd_defvaralias
> |  - [deleted]         old-branches/gnus-5_10-branch
> |  - [deleted]         old-branches/multi-tty
> |  - [deleted]         old-branches/pending
> |  - [deleted]         old-branches/rmail-mbox-branch
> |  - [deleted]         other-branches/gerd_0001
> |  - [deleted]         other-branches/gerd_int
> |  - [deleted]         other-branches/miles-orphaned-changes
> |  - [deleted]         other-branches/thomas-posix1996
> |  * [new branch]      tmp -> tmp
> `----
[...]
> find * -path '*/.bzr/branch/last-revision' | while read r; do

Your script fails to find the above branches which are nested within
a sub-directory.  You need to replace "*" with "**" (that's a zsh glob
pattern).


        Stefan

Re: Git mirrors

[Andreas Schwab]

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

>> find * -path '*/.bzr/branch/last-revision' | while read r; do
>
> Your script fails to find the above branches which are nested within
> a sub-directory.  You need to replace "*" with "**" (that's a zsh glob
> pattern).

No, you don't.  This is find.

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: Git mirrors

[Lars Magne Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

> The mirror is running now and mirroring up to Savannah.

Great!

> Also, is there a way to get Bazaar on Savannah to use curl to frob a URL
> whenever a commit is made?  If so, I could change the mirroring scheme to be
> by-commit, rather than hourly.

That seems unlikely to be allowed.  Could you just poll every ten
minutes instead?  Or if that's too heavy for the bzr machinery -- just
poll http://bzr.savannah.gnu.org/lh/emacs/ every minute and do the
mirroring if the version number of "trunk" changes.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Git mirrors

[John Wiegley]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> That seems unlikely to be allowed.  Could you just poll every ten minutes
> instead?  Or if that's too heavy for the bzr machinery -- just poll
> http://bzr.savannah.gnu.org/lh/emacs/ every minute and do the mirroring if
> the version number of "trunk" changes.

I'm afraid the machine this is running on doesn't have the kind of bandwidth
or CPU needed for such frequent polling -- it's doing other things as well.
Is hourly insufficient, Lars?

John

Re: Git mirrors

[Lars Magne Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> That seems unlikely to be allowed.  Could you just poll every ten minutes
>> instead?  Or if that's too heavy for the bzr machinery -- just poll
>> http://bzr.savannah.gnu.org/lh/emacs/ every minute and do the mirroring if
>> the version number of "trunk" changes.
>
> I'm afraid the machine this is running on doesn't have the kind of bandwidth
> or CPU needed for such frequent polling -- it's doing other things as well.
> Is hourly insufficient, Lars?

Hourly is much better than nothing.  :-)  But surely
"curl http://bzr.savannah.gnu.org/lh/emacs/" once a minute doesn't take
very many resources?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Git mirrors

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Tue, 11 Oct 2011 15:13:24 -0500
> 
>   Stefan, how I do I clone Savannah's Git mirror using SSH?  Nothing that I'm
>   trying has worked:
>   
>     git clone johnw@git.savannah.gnu.org:emacs.git
>     git clone git+ssh://johnw@git.savannah.gnu.org/emacs.git

I suggest to ask on savannah-hackers-public@gnu.org.

Re: Git mirrors

[James Cloos]

>>>>> "JW" == John Wiegley <jwiegley@gmail.com> writes:

JW>   Stefan, how I do I clone Savannah's Git mirror using SSH?  Nothing
JW>   that I'm trying has worked:
  
I took a look at a project on savannah which uses git as its primary,
and followed the links to:

  http://savannah.gnu.org/maintenance/UsingGit

That tells me that the sv repos are clonable via:

  git clone LOGIN@git.sv.gnu.org:/srv/git/PROJECT.git

(emphasis added).

That should work for emacs, too.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Git mirrors

[John Wiegley]

>>>>> James Cloos <cloos@jhcloos.com> writes:

> I took a look at a project on savannah which uses git as its primary, and
> followed the links to:

>   http://savannah.gnu.org/maintenance/UsingGit

> That tells me that the sv repos are clonable via:

>   git clone LOGIN@git.sv.gnu.org:/srv/git/PROJECT.git

> (emphasis added).

> That should work for emacs, too.

Thank you, that worked.

Now, can I install a hook into the bzr repository on Savannah so that it
touches a given URL on the server where I'm doing the mirroring?  In that case
I could update whenever a commit is done, rather than based on a time
schedule.

John

Re: Git mirrors

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Tue, 11 Oct 2011 18:37:44 -0500
> Cc: emacs-devel@gnu.org
> 
> >>>>> James Cloos <cloos@jhcloos.com> writes:
> 
> > I took a look at a project on savannah which uses git as its primary, and
> > followed the links to:
> 
> >   http://savannah.gnu.org/maintenance/UsingGit
> 
> > That tells me that the sv repos are clonable via:
> 
> >   git clone LOGIN@git.sv.gnu.org:/srv/git/PROJECT.git
> 
> > (emphasis added).
> 
> > That should work for emacs, too.
> 
> Thank you, that worked.

Is it possible to make some arrangement that would allow users of this
mirror to report the bzr revision number or bzr revision ID that
corresponds to a given git sha1?  Otherwise, it is sometimes hard to
identify the exact revision of the tree for which a bug is reported.

TIA

Re: Git mirrors

[John Wiegley]

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

> Is it possible to make some arrangement that would allow users of this
> mirror to report the bzr revision number or bzr revision ID that corresponds
> to a given git sha1?  Otherwise, it is sometimes hard to identify the exact
> revision of the tree for which a bug is reported.

Download this file from time to time:

  http://ftp.newartisans.com/pub/emacs/git-marks.txt

It correlates bzr revision ids to Git commit hashes.

John

Re: Git mirrors

[Eli Zaretskii]

> From: John Wiegley <johnw@newartisans.com>
> Cc: cloos@jhcloos.com,  emacs-devel@gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
> > Is it possible to make some arrangement that would allow users of this
> > mirror to report the bzr revision number or bzr revision ID that corresponds
> > to a given git sha1?  Otherwise, it is sometimes hard to identify the exact
> > revision of the tree for which a bug is reported.
> 
> Download this file from time to time:
> 
>   http://ftp.newartisans.com/pub/emacs/git-marks.txt
> 
> It correlates bzr revision ids to Git commit hashes.

Thanks.  But something is wrong with this data, because the last line
says

  :120999 40babedafdfeebcd5f09942ba6e7ffb15d5147ed

while the last bzr version as of this moment is 106070.

(If you invented a way to predict the future, please tell me which
numbers in next weeks lottery win ;-)

Re: Git mirrors

[John Wiegley]

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

> Thanks.  But something is wrong with this data, because the last line says

>   :120999 40babedafdfeebcd5f09942ba6e7ffb15d5147ed

> while the last bzr version as of this moment is 106070.

That's on the trunk.  There are also lots of commits on many branches.

> (If you invented a way to predict the future, please tell me which numbers
> in next weeks lottery win ;-)

4 8 15 16 23 42. ;)

John

Re: Git mirrors

[Óscar Fuentes]

John Wiegley <johnw@newartisans.com> writes:

>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Thanks.  But something is wrong with this data, because the last line says
>
>>   :120999 40babedafdfeebcd5f09942ba6e7ffb15d5147ed
>
>> while the last bzr version as of this moment is 106070.
>
> That's on the trunk.  There are also lots of commits on many branches.

On http://bzr.savannah.gnu.org/lh/emacs/ there is no branch which has
120000+ revisions. Maybe your 120999 is just the count of imported
revisions, combining all unique revisions on all branches? What Eli is
asking for is a map bzr-revision-number<->git-revision-id (possibly for
trunk and emacs-23 only) or bzr-revision-id<->git-revision-id.

[snip]

Re: Git mirrors

[John Wiegley]

>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:

> On http://bzr.savannah.gnu.org/lh/emacs/ there is no branch which has
> 120000+ revisions. Maybe your 120999 is just the count of imported
> revisions, combining all unique revisions on all branches? What Eli is
> asking for is a map bzr-revision-number<->git-revision-id (possibly for
> trunk and emacs-23 only) or bzr-revision-id<->git-revision-id.

Hmm... Now I've made files available:

  http://ftp.newartisans.com/pub/emacs/bzr-marks.txt
  http://ftp.newartisans.com/pub/emacs/git-marks.txt

They are both tables based on import IDs.  The first has the BZR
e-mail+date+somestr of the Bazaar revision, and the second has the Git
commits.  There should be some way to turn this into a correspondence table,
no?

John

Re: Git mirrors

[Óscar Fuentes]

John Wiegley <johnw@newartisans.com> writes:

> Hmm... Now I've made files available:
>
>   http://ftp.newartisans.com/pub/emacs/bzr-marks.txt
>   http://ftp.newartisans.com/pub/emacs/git-marks.txt
>
> They are both tables based on import IDs.  The first has the BZR
> e-mail+date+somestr of the Bazaar revision, and the second has the Git
> commits.  There should be some way to turn this into a correspondence table,
> no?

Yep, with those files it seems easy enough to write a script that asks
for a git rev-id and outputs the bzr rev-id, and vice-versa. Or, lacking
the script, the answer is two grep commands away.

Thanks!

Re: Git mirrors

[Andreas Schwab]

John Wiegley <johnw@newartisans.com> writes:

>   http://ftp.newartisans.com/pub/emacs/git-marks.txt
>
> It correlates bzr revision ids to Git commit hashes.

No, it doesn't.  These are internal marks.

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: Git mirrors

[John Wiegley]

>>>>> Andreas Schwab <schwab@linux-m68k.org> writes:

> John Wiegley <johnw@newartisans.com> writes:
>> http://ftp.newartisans.com/pub/emacs/git-marks.txt>
>> It correlates bzr revision ids to Git commit hashes.

> No, it doesn't.  These are internal marks.

Ack!  Do you know of a way to build a correlation table, Andreas?

John

Re: Git mirrors

[Andreas Schwab]

John Wiegley <johnw@newartisans.com> writes:

>>>>>> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> John Wiegley <johnw@newartisans.com> writes:
>>> http://ftp.newartisans.com/pub/emacs/git-marks.txt>
>>> It correlates bzr revision ids to Git commit hashes.
>
>> No, it doesn't.  These are internal marks.
>
> Ack!  Do you know of a way to build a correlation table, Andreas?

By the internal marks.

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: Git mirrors

[John Wiegley]

>>>>> Andreas Schwab <schwab@linux-m68k.org> writes:

> By the internal marks.

I looked at the two marks tables, but I'm not familiar enough with Bzr to know
the simple incantation to turn
"cyd@stupidchicken.com-20090609183929-nuq8sa1d8pep960t" into a revision
number.  With that knowledge, I can do it easily.

John

Re: Git mirrors

[Andreas Schwab]

John Wiegley <johnw@newartisans.com> writes:

>>>>>> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> By the internal marks.
>
> I looked at the two marks tables, but I'm not familiar enough with Bzr to know
> the simple incantation to turn
> "cyd@stupidchicken.com-20090609183929-nuq8sa1d8pep960t" into a revision
> number.  With that knowledge, I can do it easily.

You need to walk up the chain and count them.

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: Git mirrors

[Óscar Fuentes]

John Wiegley <johnw@newartisans.com> writes:

>>>>>> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> By the internal marks.
>
> I looked at the two marks tables, but I'm not familiar enough with Bzr to know
> the simple incantation to turn
> "cyd@stupidchicken.com-20090609183929-nuq8sa1d8pep960t" into a revision
> number.  With that knowledge, I can do it easily.

There is no easy way, AFAIK. In bzr you can simply do

bzr log -r cyd@stupidchicken.com-20090609183929-nuq8sa1d8pep960t

and it will output

------------------------------------------------------------
revno: 96032
committer: Chong Yidong <cyd@stupidchicken.com>
timestamp: Tue 2009-06-09 18:39:29 +0000
message:
  * ada-mode.texi (Installation, Compile commands)
  (Project File Overview, No project files, Set compiler options)
  (Use GNAT project file, Use multiple GNAT project files)
  (Identifier completion): Use @samp for menu items, and @kbd for key
  sequences.


It is a slow operation (8 seconds on a 2.4 GHz destktop-class GNU/Linux
machine with bzr 2.2.4. You could do instead a `log --show-ids' and
parse the output for revision numbers and revision-ids, which is much
faster.) Add to that that the same bzr revision-id may correspond to
different revision numbers, one per branch where the revision is
present, so you would need to repeat the `log' command on every branch
and output a pair (branch-name, revision-id). Although usually the Emacs
hackers are interested on two branches (`trunk' and the maintenance
branch, what was `emacs-23' until recently, `emacs-24' after the
release.) it is still a lot of work to do.

In practice, knowing the bzr revision number right away is convenient
but the hacker can operate with the revision-id, as shown above. The
files you posted contain all the required info.

Re: Git mirrors

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 12 Oct 2011 23:37:17 +0200
> 
> > I looked at the two marks tables, but I'm not familiar enough with Bzr to know
> > the simple incantation to turn
> > "cyd@stupidchicken.com-20090609183929-nuq8sa1d8pep960t" into a revision
> > number.  With that knowledge, I can do it easily.
> 
> There is no easy way, AFAIK. In bzr you can simply do
> 
> bzr log -r cyd@stupidchicken.com-20090609183929-nuq8sa1d8pep960t

  bzr revision-info cyd@stupidchicken.com-20090609183929-nuq8sa1d8pep960t

produces output that is easier to parse:

  96032 cyd@stupidchicken.com-20090609183929-nuq8sa1d8pep960t

> Add to that that the same bzr revision-id may correspond to
> different revision numbers, one per branch where the revision is
> present, so you would need to repeat the `log' command on every branch
> and output a pair (branch-name, revision-id). Although usually the Emacs
> hackers are interested on two branches (`trunk' and the maintenance
> branch, what was `emacs-23' until recently, `emacs-24' after the
> release.) it is still a lot of work to do.

It is good enough to map git sha1 to bzr revision-id; that eliminates
the dependency on the branch.  All the bzr commands that accept
revision numbers also accept revision-ids.

Re: Git mirrors

[John Wiegley]

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

>   bzr revision-info cyd@stupidchicken.com-20090609183929-nuq8sa1d8pep960t

> produces output that is easier to parse:

>   96032 cyd@stupidchicken.com-20090609183929-nuq8sa1d8pep960t

Wow.  On my VPS, doing this a single time takes 16 seconds.  Plus, I have to
do it within the right branch, which means that programmatically, I'll have to
do everyone within every branch.  That would take a little over a year.

Is there not a better to do this?  Maybe with some Python code that accesses
the repository info directly and can turn a file full of rev-info's into the
corresponding output?  Then I could add a method that only outputs the new
ones.

John

Re: Git mirrors

[Óscar Fuentes]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
>>   bzr revision-info cyd@stupidchicken.com-20090609183929-nuq8sa1d8pep960t
>
>> produces output that is easier to parse:
>
>>   96032 cyd@stupidchicken.com-20090609183929-nuq8sa1d8pep960t
>
> Wow.  On my VPS, doing this a single time takes 16 seconds.  Plus, I have to
> do it within the right branch, which means that programmatically, I'll have to
> do everyone within every branch.  That would take a little over a year.
>
> Is there not a better to do this?

As mentioned on my previous post, do a `bzr log --show-ids' and harvest
the revision numbers and revision ids from there. Here, a single `bzr
revision-info ...' takes 8 seconds, but a full `bzr log --show-ids'
takes only 30. Add a few seconds more for retrieving the numbers/ids,
and you are done in less than a minute (which still seems a lot to me,
but YMMV)

> Maybe with some Python code that accesses
> the repository info directly and can turn a file full of rev-info's into the
> corresponding output?  Then I could add a method that only outputs the new
> ones.

This is an interesting path. Hacking the bzr sources is easy and
fun. But this is not the right place for your question. When I
participated there, the guys on the bazaar ml used to be quite
collaborative with this sort of questions.

However, as confirmed by Eli, what you already provided is good enough.

Re: Git mirrors

[John Wiegley]

>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:

> As mentioned on my previous post, do a `bzr log --show-ids' and harvest the
> revision numbers and revision ids from there. Here, a single `bzr
> revision-info ...' takes 8 seconds, but a full `bzr log --show-ids' takes
> only 30. Add a few seconds more for retrieving the numbers/ids, and you are
> done in less than a minute (which still seems a lot to me, but YMMV)

Great, this will do it.  Just give me a few hours to get the new file up.

John

Re: Git mirrors

[Óscar Fuentes]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> As mentioned on my previous post, do a `bzr log --show-ids' and harvest the
>> revision numbers and revision ids from there. Here, a single `bzr
>> revision-info ...' takes 8 seconds, but a full `bzr log --show-ids' takes
>> only 30. Add a few seconds more for retrieving the numbers/ids, and you are
>> done in less than a minute (which still seems a lot to me, but YMMV)
>
> Great, this will do it.  Just give me a few hours to get the new file up.

Well, if you wish to follow that route, this is the actual command you
should use:

bzr log --show-ids -n 0

Without the `-n 0', the output only includes the leftmost part of the
DAG.

With this command:

bzr log --show-ids -n 0 --short

the number of emitted lines is halved, but it executes about 15%
*slower* and the format is different, not necessarily more difficult to
parse.

Re: Git mirrors

[John Wiegley]

>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:

> Well, if you wish to follow that route, this is the actual command you
> should use:

> bzr log --show-ids -n 0

> Without the `-n 0', the output only includes the leftmost part of the DAG.

> With this command:

> bzr log --show-ids -n 0 --short

> the number of emitted lines is halved, but it executes about 15% *slower*
> and the format is different, not necessarily more difficult to parse.

This was still too slow for something that must run on every branch, for every
hour.  Instead, I'm making a file available which maps Bzr revision ids to Git
commits:

  http://ftp.newartisans.com/pub/emacs/commit-map.txt.gz

Each individual will have to map Git commits to Bzr revision ids to Bzr rev
numbers as needed.  I.e., with bash:

  commit_to_id() {
    bzr revision-info $(zgrep " $1" commit-map.txt.gz \
                          | awk '{print $1}') \
      | awk '{print $1}'
  }

  echo $(commit_to_id f32fa9ed)

The other files have been taken down, since they do not add any information.

Also, please copy this file to your local machine when you really need to
update it.  Bandwidth costs and I'm not sure yet how much this will add up.

Thanks, John

Re: Git mirrors

[Óscar Fuentes]

John Wiegley <johnw@newartisans.com> writes:

> This was still too slow for something that must run on every branch, for every
> hour.  Instead, I'm making a file available which maps Bzr revision ids to Git
> commits:
>
>   http://ftp.newartisans.com/pub/emacs/commit-map.txt.gz
>
> Each individual will have to map Git commits to Bzr revision ids to Bzr rev
> numbers as needed.  I.e., with bash:
>
>   commit_to_id() {
>     bzr revision-info $(zgrep " $1" commit-map.txt.gz \
>                           | awk '{print $1}') \
>       | awk '{print $1}'
>   }
>
>   echo $(commit_to_id f32fa9ed)
>
> The other files have been taken down, since they do not add any information.
>
> Also, please copy this file to your local machine when you really need to
> update it.  Bandwidth costs and I'm not sure yet how much this will add up.

Have you considered implementing the above script as a CGI service on
your web server? I don't think that people will need to consult the
service more than a few times per day. A single download of the map file
will use more bandwith than the cgi script on a whole year.

Re: Git mirrors

[John Wiegley]

>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:

> Have you considered implementing the above script as a CGI service on your
> web server? I don't think that people will need to consult the service more
> than a few times per day. A single download of the map file will use more
> bandwith than the cgi script on a whole year.

It would still take 16 seconds per query.  I wrote the CGI script, but figured
that would be too annoyingly slow for developers.

John

Re: Git mirrors

[Óscar Fuentes]

John Wiegley <johnw@newartisans.com> writes:

>>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Have you considered implementing the above script as a CGI service on your
>> web server? I don't think that people will need to consult the service more
>> than a few times per day. A single download of the map file will use more
>> bandwith than the cgi script on a whole year.
>
> It would still take 16 seconds per query.  I wrote the CGI script, but figured
> that would be too annoyingly slow for developers.

Sorry, I was thinking on terms of revision ids. The CGI script would
return the bzr revision-id and the developer himself would feed it to
`bzr revision-info'. This way you save bandwith and the process is
insignificantly slower for the developer.

Re: Git mirrors

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 13 Oct 2011 01:37:21 +0200
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> Well, if you wish to follow that route, this is the actual command you
> should use:
> 
> bzr log --show-ids -n 0
> 
> Without the `-n 0', the output only includes the leftmost part of the
> DAG.
> 
> With this command:
> 
> bzr log --show-ids -n 0 --short
> 
> the number of emitted lines is halved, but it executes about 15%
> *slower* and the format is different, not necessarily more difficult to
> parse.

Again, I think revno's are not necessary, so John needs not waste his
time and resources on this.

But as long as we are talking about "log -n0", installing the
history_db plugin significantly speeds up "bzr log" when it needs to
reference revisions merged from other branches.

Re: Git mirrors

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Wed, 12 Oct 2011 17:35:45 -0500
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   bzr revision-info cyd@stupidchicken.com-20090609183929-nuq8sa1d8pep960t
> 
> > produces output that is easier to parse:
> 
> >   96032 cyd@stupidchicken.com-20090609183929-nuq8sa1d8pep960t
> 
> Wow.  On my VPS, doing this a single time takes 16 seconds.

Yes, it's slow.  I will file a bug against it.

> Is there not a better to do this?

Yes, there is: don't.  As I already wrote, there's no need for you to
do this translation at all.  It is enough to provide the bzr
revision-id that corresponds to each git sha1.  Any Emacs developer
who wants to see the details of the revision can use the revision-id
directly, or convert it to revno if she wants.  No need for your
scripts to do that.

Would that solve the problem?

Re: Git mirrors

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

[snip]

> Add to that that the same bzr revision-id may correspond to
> different revision numbers, one per branch where the revision is
> present, so you would need to repeat the `log' command on every branch
> and output a pair (branch-name, revision-id).

Sorry, the above should be "and output a triplet

(git-revision-id, bzr-branch-name, bzr-revision-number)

[snip]

Re: Git mirrors

[Ted Zlatanov]

On Tue, 11 Oct 2011 15:48:27 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> OK, I'll just ask why Savannah offers Git hosting for GNU projects.

LMI> I have no idea what all y'all are arguing about.  I asked for an
LMI> up-to-date git mirror to be set up, and that's apparently being done.

LMI> So this discussion is redundant.

On Tue, 11 Oct 2011 10:48:05 -0400 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Tue, 11 Oct 2011 08:19:08 -0500
>> 
EZ> I forgot that Savannah already provides such a mirror.  So I guess
EZ> what you need to do is make it update more frequently, and then
EZ> (hopefully) we will be free of these endless flame-discuss threads.
>> 
>> Not more frequently, but on every commit, so it's *reliable*.
>> 
>> And make it official so we don't have 50 unofficial ones.

EZ> It is as official as it gets: I saw it on Savannah pages for the Emacs
EZ> project.

Thank you both.  I'm happy with that.

Ted

Re: Git mirrors

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > Is Emacs a tool or a weapon?

Both, of course.  It's a tool for the users and a "weapon" (ie, an
advocacy tool) for the GNU Project and the Free Software Movement in
opposing proprietary software.

Richard has been shouting this message from the rooftops since 1985.

Re: Git mirrors

[Richard Stallman]

    Why does Savannah offer Git hosting if you feel even providing a
    read-only Git mirror harms the GNU project?

That is a good question.  If I were considering this now, I think I
would say, "We should give BZR much more support than GIT", for the
sort of reasons I have already stated.


-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Git mirrors

[Ted Zlatanov]

On Tue, 11 Oct 2011 18:02:22 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS>     Why does Savannah offer Git hosting if you feel even providing a
RS>     read-only Git mirror harms the GNU project?

RS> That is a good question.  If I were considering this now, I think I
RS> would say, "We should give BZR much more support than GIT", for the
RS> sort of reasons I have already stated.

Thank you for the considerate response.  Your position makes sense with
this clarification.

Ted

Re: Git mirrors

[Richard Riley]

Glenn Morris <rgm@gnu.org> writes:

> Ted Zlatanov wrote:
>
>> I think it would benefit the GNU Emacs project, the Emacs developers and
>> maintainers, and the Emacs community as a whole if there was an official
>> read-only Git mirror of the Emacs repository that was updated with every
>> Bazaar push.
>
> I just want to make the point that since Bazaar is a GNU project, IMO
> this would not benefit the GNU project as a whole. (I'm not saying don't
> do it, just making a point.)

No but it would benefit lots of others who use Emacs. bzr is
unpredictable, slow and frequently doesnt work at all. Git mirrors
generally do as well as being far faster and easier for a lot of people
who use git in their daily lives because it works so well. Emacs also has
a great git interface in Magit-

Re: Git mirrors

[Eli Zaretskii]

> From: Richard Riley <rileyrg@googlemail.com>
> Date: Sat, 08 Oct 2011 11:26:37 +0200
> 
> bzr is unpredictable, slow and frequently doesnt work at all.

I use bzr daily, on several different machines and systems, and my
experience is nowhere near that of yours.  I wonder whether this is
based on recent experience or on something that is old enough to
require revisiting, perhaps with newer versions of the bzr client.

I also wonder whether we can offer you (and others) some sort of
simple cookbook that would make your life with bzr easier, to the
degree that you will decide to contribute to Emacs regardless.  I'm
forced to use git in several projects to which I contribute, and as
much as I dislike it, I've learned a few simple skills that let me
continue my contribution.  I don't think a casual contributor needs to
know more than a small number of bzr commands.  Maybe we can help you
with that.

Re: Git mirrors

[Thierry Volpiatto]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Glenn Morris <rgm@gnu.org> writes:
>
>> Trying to be constructive about this, this would be helpful, but presumably
>> a fully automatic sync is not possible, or someone would have done it by
>> now.
>
> I have my own fully-automated sync happening here on my own machine, using
> git-bzr and bzr-fast-import, so I can't imagine it would be any harder for a
> server to do.
Do you sync all branches or only trunk?
I use git-bzr too, but only for trunk and i wonder how do you sync all
branches if it's the case.

>> If someone can do it, please work to get it done on Savannah so that we
>> never have to have this discussion again.
>
> Give me ssh access and I'll do it.
Would be great.

-- 
 𝕋𝕙𝕚𝕖𝕣𝕣𝕪
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Git mirrors

[John Wiegley]

>>>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Do you sync all branches or only trunk?  I use git-bzr too, but only for
> trunk and i wonder how do you sync all branches if it's the case.

At present it is only trunk, but it looks like it should be possible to mirror
all branches, I'll just have to check out all the Bazaar branches someplace,
so that git-bzr can turn them into Git branches.

John

Re: Git mirrors

[Thierry Volpiatto]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Do you sync all branches or only trunk?  I use git-bzr too, but only for
>> trunk and i wonder how do you sync all branches if it's the case.
>
> At present it is only trunk, but it looks like it should be possible to mirror
> all branches, I'll just have to check out all the Bazaar branches someplace,
> so that git-bzr can turn them into Git branches.
So IIUC to make a git repo containing all Emacs branches, it is needed
to checkout all these branches in the bzr repo and then 
git-bzr clone <root of bzr repo>?
  
-- 
 𝕋𝕙𝕚𝕖𝕣𝕣𝕪
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Git mirrors

[John Wiegley]

>>>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> So IIUC to make a git repo containing all Emacs branches, it is needed to
> checkout all these branches in the bzr repo and then git-bzr clone <root of
> bzr repo>?

I have to checkout all the branches within a "multi-site" repository, and then
do:

  git bzr add <BRANCH> <path to checkout of BRANCH>
  git bzr fetch <BRANCH>

Wash, rinse, repeat.

So far I have not found a way to get a listing of all the branches in a Bazaar
repository, nor how to mirror them.  This looks like it may need some
scripting.

John

Re: Git mirrors

[Thierry Volpiatto]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> So IIUC to make a git repo containing all Emacs branches, it is needed to
>> checkout all these branches in the bzr repo and then git-bzr clone <root of
>> bzr repo>?
>
> I have to checkout all the branches within a "multi-site" repository, and then
> do:
>
>   git bzr add <BRANCH> <path to checkout of BRANCH>
>   git bzr fetch <BRANCH>
Ok thanks.

> Wash, rinse, repeat.
>
> So far I have not found a way to get a listing of all the branches in a Bazaar
> repository, nor how to mirror them.  This looks like it may need some
> scripting.
>
> John
>
>
>

-- 
 𝕋𝕙𝕚𝕖𝕣𝕣𝕪
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Git mirrors

[James Cloos]

>>>>> "JW" == John Wiegley <jwiegley@gmail.com> writes:

JW> So far I have not found a way to get a listing of all the branches in a Bazaar
JW> repository, nor how to mirror them.  This looks like it may need some scripting.

For the savannah repos, you can look at, eg,

  rsync://bzr.sv.gnu.org/bzr/emacs/

to see the list of branches in that repo.

The directories are not necessarily all branches; you'll need to check
for a .bzr sub-directory in each.

Something like:

  rsync -a  rsync://bzr.sv.gnu.org/bzr/emacs/|egrep bzr/branch-format$

should work well to detect all of the branches.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Git mirrors

[John Wiegley]

>>>>> James Cloos <cloos@jhcloos.com> writes:

> For the savannah repos, you can look at, eg,

>   rsync://bzr.sv.gnu.org/bzr/emacs/

> to see the list of branches in that repo.

I need to sync the Bazaar repository locally to make all this mirroring be
much faster.  The rsync URL above works just fine.

Thanks!
  John

Re: Git mirrors

[Stephen J. Turnbull]

John Wiegley writes:

 > So far I have not found a way to get a listing of all the branches
 > in a Bazaar repository,

Install bzrtools.  "bzr branches <URL>" is alleged to do the trick.

 > nor how to mirror them.  This looks like it may need some
 > scripting.

Re: Git mirrors

[Andreas Schwab]

http://article.gmane.org/gmane.emacs.devel/119039

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: Git mirrors

[John Wiegley]

>>>>> Andreas Schwab <schwab@linux-m68k.org> writes:

> http://article.gmane.org/gmane.emacs.devel/119039

Nice!  Thanks, Andreas.

John

Re: Git mirrors

[Lars Magne Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

> Nice!  Thanks, Andreas.

And thank you for setting this up.  I think it's going to make life
easier for bug responders.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Git mirrors

[Thierry Volpiatto]

Andreas Schwab <schwab@linux-m68k.org> writes:

> http://article.gmane.org/gmane.emacs.devel/119039

Thanks.

-- 
 𝕋𝕙𝕚𝕖𝕣𝕣𝕪
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Git mirrors

[Stephen J. Turnbull]

John Wiegley writes:

 > I have my own fully-automated sync happening here on my own
 > machine, using git-bzr and bzr-fast-import, so I can't imagine it
 > would be any harder for a server to do.

(If you haven't already done so) May I suggest that you make the bzr
revision id available somehow for every revision (probably use of "git
notes" would be best)?  If the canonical git mirror always makes the
revid available, you can ask reporters to fish it out.  Somebody[tm]
will quickly write a command to extract it and do something vc.el-y
with it (eg, bzr diff, bzr revert).  And of course report-emacs-bug
can be trained to DTRT here.

Note that you *don't* need to do this immediately for past revisions.
If some bzr-lover wants them, because git notes are ahistorical, they
can be added later by sis (a Sufficiently Intelligent Script), and in
any case they'll rapidly become obsolete.

Re: Git mirrors

[John Wiegley]

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

> (If you haven't already done so) May I suggest that you make the bzr
> revision id available somehow for every revision (probably use of "git
> notes" would be best)?  If the canonical git mirror always makes the revid
> available, you can ask reporters to fish it out.  Somebody[tm] will quickly
> write a command to extract it and do something vc.el-y with it (eg, bzr
> diff, bzr revert).  And of course report-emacs-bug can be trained to DTRT
> here.

I will see what can be done.  Due to the nature of Git, my own Bazaar mirror
has entirely different commit ids than what Savannah has.

This can be dealt with in the following ways:

  1. Start a new mirror, telling people to look there if they wish to follow
     Git.

  2. Merge the current Git mirror into mine.  This has the downside that every
     commit before that merge would be duplicated.

  3. Overwrite the current mirror with my own.  This will wreak havoc
     throughout the realm, as everyone on their next pull would merge their
     own histories with the new mirror, thus duplicating each commit not on
     the server, but on every client machine who had cloned before now.

> Note that you *don't* need to do this immediately for past revisions.  If
> some bzr-lover wants them, because git notes are ahistorical, they can be
> added later by sis (a Sufficiently Intelligent Script), and in any case
> they'll rapidly become obsolete.

Notes can be useful, but they don't propagate through a clone.

What I do have is an upstream-git-map file, which I can make available over
HTTP.  Simply grep'ing this file will correlate BZR ids to Git commit hashes,
and vice-versa.

John

Re: Git mirrors

[Andreas Schwab]

John Wiegley <jwiegley@gmail.com> writes:

> I will see what can be done.  Due to the nature of Git, my own Bazaar mirror
> has entirely different commit ids than what Savannah has.

That should not be the case, since git ids are solely based on
contents.  Most likely you are doing something wrong.

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: Git mirrors

[John Wiegley]

>>>>> Andreas Schwab <schwab@linux-m68k.org> writes:

>> I will see what can be done.  Due to the nature of Git, my own Bazaar
>> mirror has entirely different commit ids than what Savannah has.

> That should not be the case, since git ids are solely based on contents.
> Most likely you are doing something wrong.

Hmm... the commits match at the beginning of history, but they diverge in the
middle somehow.  I'll try to find out what caused this.  If it was a bug in
the git-bzr process that got fixed recently, then we still have a decision to
make.

John

Re: Git mirrors

[John Wiegley]

>>>>> Andreas Schwab <schwab@linux-m68k.org> writes:

> John Wiegley <jwiegley@gmail.com> writes:
>> I will see what can be done.  Due to the nature of Git, my own Bazaar
>> mirror has entirely different commit ids than what Savannah has.

> That should not be the case, since git ids are solely based on contents.
> Most likely you are doing something wrong.

I found the divergence, and something is wrong with my git-bzr.

John

Bazaar:

,----
| revno: 7238
| committer: Paul Reilly <pmr@pajato.com>
| timestamp: Sat 1994-04-30 23:08:15 +0000
| message:
|   Initial revision
| added:
|   src/s/dgux5-4R2.h
|   src/s/dgux5-4R3.h
`----

Savannah Git Mirror:

,----
| commit 48df2e64c678ce4bc119ec737d08f80c36135e31
| Author: Paul Reilly <pmr@pajato.com>
| Date:   Sat Apr 30 23:08:15 1994 +0000
| 
|     Initial revision
| 
|  src/s/dgux5-4R2.h |   46 +++++++++++++++++++++++++++++++++++++++++
|  src/s/dgux5-4R3.h |   59 +++++++++++++++++++++++++++++++++++++++++++++++++++++
|  2 files changed, 105 insertions(+), 0 deletions(-)
`----

My Git Mirror:

,----
| commit 52a945a9afc999d033548bcdc80f7105075ee5f6
| Author: Paul Reilly <pmr@pajato.com>
| Date:   Sat Apr 30 23:08:15 1994 +0000
| 
|     Initial revision
| 
|  src/s/dgux5-4R3.h |   59 +++++++++++++++++++++++++++++++++++++++++++++++++++++
|  1 files changed, 59 insertions(+), 0 deletions(-)
`----

Re: Git mirrors

[Paul Michael Reilly]

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

On Fri, Oct 7, 2011 at 5:02 AM, John Wiegley <jwiegley@gmail.com> wrote:

> >>>>> Andreas Schwab <schwab@linux-m68k.org> writes:
>
> > John Wiegley <jwiegley@gmail.com> writes:
> >> I will see what can be done.  Due to the nature of Git, my own Bazaar
> >> mirror has entirely different commit ids than what Savannah has.
>
> > That should not be the case, since git ids are solely based on contents.
> > Most likely you are doing something wrong.
>
> I found the divergence, and something is wrong with my git-bzr.
>
> John
>
> Bazaar:
>
> ,----
> | revno: 7238
> | committer: Paul Reilly <pmr@pajato.com>
> | timestamp: Sat 1994-04-30 23:08:15 +0000
> | message:
> |   Initial revision
> | added:
> |   src/s/dgux5-4R2.h
> |   src/s/dgux5-4R3.h
> `----
>
> Savannah Git Mirror:
>
> ,----
> | commit 48df2e64c678ce4bc119ec737d08f80c36135e31
> | Author: Paul Reilly <pmr@pajato.com>
> | Date:   Sat Apr 30 23:08:15 1994 +0000
> |
> |     Initial revision
> |
> |  src/s/dgux5-4R2.h |   46 +++++++++++++++++++++++++++++++++++++++++
> |  src/s/dgux5-4R3.h |   59
> +++++++++++++++++++++++++++++++++++++++++++++++++++++
> |  2 files changed, 105 insertions(+), 0 deletions(-)
> `----
>
> My Git Mirror:
>
> ,----
> | commit 52a945a9afc999d033548bcdc80f7105075ee5f6
> | Author: Paul Reilly <pmr@pajato.com>
> | Date:   Sat Apr 30 23:08:15 1994 +0000
> |
> |     Initial revision
> |
> |  src/s/dgux5-4R3.h |   59
> +++++++++++++++++++++++++++++++++++++++++++++++++++++
> |  1 files changed, 59 insertions(+), 0 deletions(-)
> `----
>

Wouldn't you just know it. :-)

-pmr

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

Re: Git mirrors

[Stephen J. Turnbull]

John Wiegley writes:

 >   2. Merge the current Git mirror into mine.  This has the downside
 >      that every commit before that merge would be duplicated.

Hrm.  Might almost be worth it! ;-)

 > Notes can be useful, but they don't propagate through a clone.

That figures.

 > What I do have is an upstream-git-map file, which I can make available over
 > HTTP.  Simply grep'ing this file will correlate BZR ids to Git commit hashes,
 > and vice-versa.

Should do the trick, indeed!

Re: Git mirrors

[Leo]

On 2011-10-07 04:50 +0800, Lars Magne Ingebrigtsen wrote:
> But it's getting to a point where I'm kinda wishing that people setting
> up git mirrors would just stop doing that.

I rely on such people's work to be able to contribute back to Emacs. It
would inconvenience/alienate many people.

Leo

Re: Git mirrors

[Bastien]

A good picture is worth 1000 words and a good laugh is worth 
1000 flamewars.  Enjoy:

http://www.universalsubtitles.org/en/videos/INSp3igHIJyl/info/The%20Orgfather/

PS: Hindi speakers, please turn sound off.

PS2: Careful, org-mode private jokes inside.

-- 
 Bastien

Git mirrors

[François Pinard]

Hi, Org people.

GitHub has a few niceties, like easy forking, pull requests and such.  I
notice https://github.com/jwiegley/org-mode in particular, which does
not seem to be itself a fork of another GitHub repository, so I presume
it forked directly from the official Git site for Org mode, which itself
does not provide the same collaboration facilities as GitHub.

The GitHub home page for John Wiegly says the org-mode project was
updated two weeks ago, so I suspect it lags on the official Git site.  A
message on the mailing list speaks of this repository as the home for
Org-X, so I also suspect this fork is not genuine, and not a way to get
on GitHub the real, pure, Org mode.

In the Org project, how commits are usually transmitted?  I would not
think maintainers are pulling our various repositories in theirs to then
consider cherry picking, and it would require that we all set up Git
servers.  We could use GitHub as a way to avoid servers, but it feel
strange using GitHub to communicate with Org maintainers while they do
not themselves choose to keep an "official" mirror of Org on GitHub.

Commits are going to be sent as email apply-able patches?  Maybe this is
all documented somewhere already, and I just did not read enough?

François

Re: Git mirrors

[Nick Dokos]

François Pinard <pinard@iro.umontreal.ca> wrote:

> Hi, Org people.
> 
> GitHub has a few niceties, like easy forking, pull requests and such.  I
> notice https://github.com/jwiegley/org-mode in particular, which does
> not seem to be itself a fork of another GitHub repository, so I presume
> it forked directly from the official Git site for Org mode, which itself
> does not provide the same collaboration facilities as GitHub.
> 
> The GitHub home page for John Wiegly says the org-mode project was
> updated two weeks ago, so I suspect it lags on the official Git site.  A
> message on the mailing list speaks of this repository as the home for
> Org-X, so I also suspect this fork is not genuine, and not a way to get
> on GitHub the real, pure, Org mode.
> 

It does not make any difference from where you get it. You can mirror
the org git repo from orgmode.org on github if you want: nothing is
stopping you. Then use the github collaboration tools.

> In the Org project, how commits are usually transmitted?  I would not
> think maintainers are pulling our various repositories in theirs to then
> consider cherry picking, and it would require that we all set up Git
> servers.  We could use GitHub as a way to avoid servers, but it feel
> strange using GitHub to communicate with Org maintainers while they do
> not themselves choose to keep an "official" mirror of Org on GitHub.
> 

That's up to each maintainer: they can apply patches sent as email, or
they can cherry-pick commits from a remote branch if they want.

There is nothing strange about using github to communicate with the
maintainers: set up your clone, create a branch with your modification
and let the maintainers know about it. That's how many linux maintainers
did things while kernel.org was down last year. All that changed for
Linus was that he pulled from a different repo.

OTOH, some maintainers would prefer emailed patches instead; some
wouldn't care one way or the other. If they don't want to touch your
repo, you can't make them, so the best thing to do is ask which is their
preferred method. Or do as Bernt Hansen was doing: submit a patch in
email and also point to a branch that contains that patch (and that
patch alone) on top of a clone of the official git repo. This last
method has the advantage that it tells the maintainer the exact state of
the tree when the patch was applied, which allows problematic merges
to be resolved more easily (see Linus's comments in

 https://plus.google.com/111049168280159033135/posts/Xmycxn7VwHV

for some details - but that's useful mostly for maintainers, not
for patch contributors; otoh, it's always nice to know more than
the absolute minimum necessary.)

> Commits are going to be sent as email apply-able patches?  Maybe this is
> all documented somewhere already, and I just did not read enough?
> 

``Documented'' is probably too strong a word, but once you've been on
the ML for a while, you start discerning the customs of the people
living there: emailed patches is indeed the standard way (not least
because patchwork captures them, so they don't get lost in some old
email thread).

Nick

Disclaimer: I'm not a maintainer, so if I've got things wrong, I hope
one of them will correct me.

Re: Git mirrors

[Bastien]

Nick Dokos <nicholas.dokos@hp.com> writes:

> OTOH, some maintainers would prefer emailed patches instead;

FWIW, I prefer patches sent to this list for two reasons: they get
quickly tested by many people (i.e. faster than external branches) 
and bacause patches get caught on the patchwork.  Even if i don't
use the patchwork server to apply patches, I use it as a "watchlist".

-- 
 Bastien