9 ms·

I went back and looked at the older discussion, and it doesn't paint Stallman very well as the head of a project. He pins the question of whether to keep using

I went back and looked at the older discussion, and it doesn't paint Stallman very well as the head of a project. He pins the question of whether to keep using bzr not on whether it is good or whether the Emacs developers want it, but on whether it's being "maintained". But then he seems to define maintenance as having fixed a specific bug that's been around for over a year, blocking a point release. He admits that he can't follow the developers list to see if they're genuinely doing active maintenance (reasonable enough: he has a lot on his plate), but also won't accept the testimony of Emacs developers that the mailing list is dead and there's no evidence of real maintenance. When questioned, he says that there's too much at stake to abandon bzr if it can be avoided at all. But the proposed replacement is GPL software. This is just madness. Refs: http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00906.html http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg009.... http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00870.html http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg008... (and surrounding posts).

blumentopf 13y ago
> it doesn't paint Stallman very well as the head of a project Is this news to you? Cf. e.g. http://www.jwz.org/doc/lemacs.html http://www.jwz.org/doc/lemacs.html
- hyperpape 13y ago
  shrug More confirmation.
- vezzy-fnord 13y ago
  Not to mention his insistence on GNU Hurd being based on Mach, which pretty much ended up killing the project.
  - IgorPartola 13y ago
    That's a simplistic view. First, the GNU project is very much alive: the GNU tools are used in a huge number of operating systems and are installed on a staggering number of devices. I would bet that the system you are writing this comment from is running thanks to the GNU software. Second, it is debatable whether sticking to Hurd was a good or a bad idea technically. Imagine if Stallman and co. managed to convince a good number of developers that it was a good idea and the kernel was competitive with Linux, BSD's, etc. If you believe you have a technically superior vision for your product, should you compromise on it just because people who do not share in your vision will not join you? In the end, I think what killed the pure GNU/Hurd OS was bad PR and absolutism. Hurd as a technical question was just a small part of that. Remember, the debate between the Free and the Open Source guys was pretty fierce. Today we use terms like FOSS to describe all open software, but when Linux and Hurd were young these were different camps with opposing philosophies, and the one that appealed to more developers won out. In simplistic terms, you can think of this as the VHS vs Betamax debate. Can you blame the Betamax backers for continuing to try to push it and "killing" it as a result?
    - vezzy-fnord 13y ago
      Wait. You misunderstood me. I didn't say the entire GNU Project is dead. Hell no. When I said "project", I was referring specifically to GNU Hurd. Also my statement was going by the words of the Hurd's former project leader Thomas Bushnell: "RMS was a very strong believer -- wrongly, I think -- in a very greedy-algorithm approach to code reuse issues. My first choice was to take the BSD 4.4-Lite release and make a kernel. I knew the code, I knew how to do it. It is now perfectly obvious to me that this would have succeeded splendidly and the world would be a very different place today. RMS wanted to work together with people from Berkeley on such an effort. Some of them were interested, but some seem to have been deliberately dragging their feet: and the reason now seems to be that they had the goal of spinning off BSDI. A GNU based on 4.4-Lite would undercut BSDI. So RMS said to himself, "Mach is a working kernel, 4.4-Lite is only partial, we will go with Mach." It was a decision which I strongly opposed. But ultimately it was not my decision to make, and I made the best go I could at working with Mach and doing something new from that standpoint. This was all way before Linux; we're talking 1991 or so." [1] http://www.groklaw.net/article.php?story=20050727225542530 http://www.groklaw.net/article.php?story=20050727225542530 [1]
      - dragonwriter 13y ago
        Note, in regard to Bushnell's quote, that "1991 or so" and "way before Linux" are contradictory. (Or, at least, require an strained definition of "way before"; Linux was first released in 1991.)
    - Sssnake 13y ago
      >the GNU tools are used in a huge number of operating systems You mean linux? That isn't a huge number. >and are installed on a staggering number of devices The staggering number of devices you refer to almost exclusively run busybox or one of the similar projects. GNU software is hugely bloated and not a good choice for embedded systems. >Second, it is debatable whether sticking to Hurd was a good or a bad idea technically No, it was fine technically. It had no developers and so nothing happened. Minix exists, obviously microkernels are possible.
  - asveikau 13y ago
    Apple still insists on building their kernel atop Mach, and it doesn't seem to stop their momentum. (Even though it's kind of a strange choice.)
    - gillianseed 13y ago
      From what I understand, the Mach kernel which is now used in XNU is not the Mach micro kernel (3.0 >) but based upon the pre-micro-kernel 2.5 version of Mach. I'm not sure where I read this originally but I just googled this source which seems to back it up: http://www.roughlydrafted.com/0506.mk3.html http://www.roughlydrafted.com/0506.mk3.html
      - asveikau 13y ago
        I am not intimately familiar with the history of Mach, but what I do see is that in the late 80s and early 90s these two groups (NeXT and GNU) seeing Mach as the future (a position that makes no sense at a later time), and having vastly different outcomes. I don't know much about how these people work, but I always figured Mach at Apple is just about momentum and familiarity of contributors, rather than technology. NeXT hired Tevanian who worked on Mach at CMU, they spent roughly a decade hacking on Mach, then Apple did the same. I'd imagine they employ people who know Mach well and haven't seen it as worthwhile to replace it. I even remember they had this goofy project "MkLinux", which sought to put Linux in the position that BSD carries with XNU, on top of Mach... Just goofy stuff, unless you figure they had Mach hackers on staff.
      - empthought 13y ago
        According to the Apple docs XNU is based on Mach 3.0. https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/Mach/Mach.html https://developer.apple.com/library/mac/documentation/Darwin...
        valleyer 13y ago
        That's misleading. Apple merged in a bunch of Mach 3 code but still maintains the architecture of Mach 2.5 (i.e., Mach + BSD both running in supervisor mode in one big monolith; no BSD server; xnu is not a microkernel…).
  - gillianseed 13y ago
    Back when the choice was made, micro-kernels was all the rage in both academia and commercial ventures, and Stallman chose Mach since he thought it would speed up development, he was hardly alone in choosing Mach at this time, Apple (MkLinux, NeXTSTEP), IBM (Workplace OS) amongst others. He fully acknowledged that he made a mistake in going with Mach and as soon as Linux took off FSF focused on providing the necessary software to combine with Linux into an operating system and placed Hurd on 'life support', where it's been ever since.
    - maxlybbert 13y ago
      IIRC, ARPA at some point was more interested in funding projects based on Mach than based on any other kernel.
- belorn 13y ago
  I'm not sure that conversation is a good example of what you are trying to describe. Let's see if someone did the following things to the python project: 1#: Hire away the package maintainer. Then rather than continue and finish any current work, effectively remove that person from the community project. 2#: Redesign underlying structure of the project (like say, PyPy), but don't discuss any changes with the community. No PEPs, no discussion on mailing lists, no communication what so ever. 3#: Ignore current list of new feature being worked at. Community goals are unimportant. 4#: Add code regression! Do not care about maintaining performance. 5#: Demand that the changes get implemented immediately in next official release. Would anyone expect that to actually work today? Sure, Stallman could be more diplomatic and find (and succeed) with a middle ground solution, but the above steps are not how you join an ongoing software project.
  - hamburglar 13y ago
    I tried to read that conversation in a neutral light, because I think RMS and JWZ are both kind of ... polarizing personalities, but RMS really came off as a stubborn, ineffective whiner in that whole thread. In particular "you hired away my maintainer" is a pathetic excuse for not releasing something for so long. Anybody could have hired away your maintainer, and you'd have to soldier on; it has no relevance that your maintainer went to a "competing" (in your territorial view) project. I also read the argument about the redesign of the event system and was pretty flabbergasted. The argument seems to reduce to "lucid emacs decided to design a proper event datatype because having an event be entirely represented by a simple integer keycode both lost information and made it impossible to represent certain keystrokes" versus "but ints are simple and backward compatible!"
    - lmm 13y ago
      Funny, I had the opposite view. I guess your opinion of the personalities really does change everything.
      - hamburglar 13y ago
        There is one (and only one) other possibility, which is that you and I both read the conversation with flawless objectivity, and that you are wrong. :D
- revelation 13y ago
  > I couldn't change the plans, so I had to make the best of them. I suggested a design to him, one oriented toward editing formatted text--a feature I wanted Emacs to have, eventually. Hah, 20 years in the making!
- mempko 13y ago
  the exchange made lucid seem like a bunch of assholes
  - eropple 13y ago
    Care to explain? I thought that the Lucid guys made reasonable technical arguments (especially in light of, y'know, history, over the last twenty years) and that RMS was attempting to both grandstand and emotionally manipulate people into adopting his preferred position.
cpach 13y ago
I thought RMS had resigned as Emacs’ maintainer? http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02140.html http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg021...
- hyperpape 13y ago
  Maybe--but the tenor of the discussion strongly suggests, if not implies, that he makes the call about whether they can leave bzr.
- dded 13y ago
  One of the reasons I chose GNU Emacs over XEmacs was a feeling that GNU Emacs will be maintained, even advanced, for as long as RMS has the strength to type. It's his baby. (There were other reasons, the big one being momentum. XEmacs didn't run on the platform I was on for a long time, so it would have been a switch.)
  - aaronem 13y ago
    An excellent point; for example, although I don't have any reason to think RMS himself did this, Emacs 24.4 will have file change notification support across all platforms where it compiles and where such notifications are available. I grant that's a somewhat overdue feature for Emacs to have (e.g., I've wanted it ever since I set up Dropbox to synchronize my org-mode files across all my boxes), but it's definitely evidence that Emacs isn't lacking of maintenance and improvement. I wonder: If Emacs rarely gains new features in core, is it because there aren't enough developers doing enough to improve it, or rather because people are having a hard time thinking up new features to add which Emacs doesn't already have?
    - agumonkey 13y ago
      Lisp systems legacy I suppose, the core is ~tiny, everything else is a library.
      - aaronem 13y ago
mathattack 13y ago
For better or worse, having a vision is a very different skillset from having the management skillset to make things happen. Sometimes people deride management when talking about the importance of vision and leadership. There is also the current trend of companies giving up managers entirely. RMS is a prime example of why management is an important skill. It is inefficient for him to do everything himself. It's also inefficient for him to chase people down for all the details. If he had a solid COO who understood his vision, his organization would be much more effective.
stiff 13y ago
I think this is more inertia than anything else. It is pretty obvious that Stallman isn't the easiest person to talk to, but he has consistently put huge amount of efforts into GNU for lots of years, and, whatever he did as the maintainer, seems to have worked out pretty much in the end. If there was anyone as active in the Emacs community today as Stallman was in his prime, they could easily push through changes despite Stallman's disagreement, via a fork or otherwise, but there isn't such a person, and that is that. Consider that it has been almost 30 years since GNU Emacs started, for most of this time RMS has been the maintainer, and GNU Emacs continues to this day to be the most advanced, popular and active Emacs there is, while the various forks in existence like XEmacs, SXEmacs lost steam pretty quickly. So it certainly hasn't been all bad on his side.
- jedrek 13y ago
  The popularity of a specific fork of Emacs is a moot point, it's the popularity of Emacs as an editor (or should I say, as a platform?) that is at issue. Stallman was active, how that he's not active he needs to either defer to people who are active or watch as fewer and fewer people take advantage of his work.
  - stiff 13y ago
    Stallman doesn't have much influence on Emacs development itself anymore, but Emacs is a GNU project, Stallman is still the head of GNU, and a move to another VCS would be a major organizational change. I too wish he would be less hard-headed about this, but lets not overblow this issue out of proportion.
    - lstamour 13y ago
      In replies, he says he doesn't oppose the move to git. Most devs who've replied support git. There's already a mirror. Let's not make mountains out of molehills...
- ams6110 13y ago
  Over those 30 years the emacs codebase must have moved through several revision control systems. Why is moving to another one such a big deal?
chebucto 13y ago
As he said, 'more than Emacs is at stake here.'.[1] I presume this refers to Bazaar's status as part of the GNU project, and that RMS did not want to write off part of GNU without being certain he needed to. Regardless, he has since OKd the switch from bzr: I don't insist that Emacs should stay with bzr. I chose to support bzr because it was still a contender at the time. [2] [1] https://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00934.html https://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00... [2] https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00014.html https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00... edit: formatting
- codereflection 13y ago
  I think Stallman is being reasonable here.
  - dredmorbius 13y ago
    He's not always an unreasonable man. https://paragraft.wordpress.com/2008/05/01/progress-and-the-unreasonable-man/ https://paragraft.wordpress.com/2008/05/01/progress-and-the-...
- kro0ub 13y ago
  I think the subsequent OK'ing is unfortunate. Attracting younger hackers shouldn't be a more important goal than integrity.
  - secoif 13y ago
    What does this have to do with integrity?
    - kro0ub 13y ago
      I mean, don't not fixing what ain't broke is certainly a matter of integrity. Fixing something to the latest hippest new fad just to "attract young hackers" detracts from integrity. Making the editor an awesome badass attractive editor should be enough. Otherwise you'll only be attracting groupthink-prone douchebags, anyway.
malandrew 13y ago
"When questioned, he says that there's too much at stake to abandon bzr if it can be avoided at all." The big difference between then and now is that this time you have a very competent developer with an exceptional reputation offering to lead the migration. With esr leading things, there is a lot less at risk.
- logjam 13y ago
  So you're saying that ESR will do for Emacs what he did for...fetchmail.

blumentopf 13y ago

> it doesn't paint Stallman very well as the head of a project Is this news to you? Cf. e.g. http://www.jwz.org/doc/lemacs.html http://www.jwz.org/doc/lemacs.html

hyperpape 13y ago
shrug More confirmation.
vezzy-fnord 13y ago
Not to mention his insistence on GNU Hurd being based on Mach, which pretty much ended up killing the project.
- IgorPartola 13y ago
  That's a simplistic view. First, the GNU project is very much alive: the GNU tools are used in a huge number of operating systems and are installed on a staggering number of devices. I would bet that the system you are writing this comment from is running thanks to the GNU software. Second, it is debatable whether sticking to Hurd was a good or a bad idea technically. Imagine if Stallman and co. managed to convince a good number of developers that it was a good idea and the kernel was competitive with Linux, BSD's, etc. If you believe you have a technically superior vision for your product, should you compromise on it just because people who do not share in your vision will not join you? In the end, I think what killed the pure GNU/Hurd OS was bad PR and absolutism. Hurd as a technical question was just a small part of that. Remember, the debate between the Free and the Open Source guys was pretty fierce. Today we use terms like FOSS to describe all open software, but when Linux and Hurd were young these were different camps with opposing philosophies, and the one that appealed to more developers won out. In simplistic terms, you can think of this as the VHS vs Betamax debate. Can you blame the Betamax backers for continuing to try to push it and "killing" it as a result?
  - vezzy-fnord 13y ago
    Wait. You misunderstood me. I didn't say the entire GNU Project is dead. Hell no. When I said "project", I was referring specifically to GNU Hurd. Also my statement was going by the words of the Hurd's former project leader Thomas Bushnell: "RMS was a very strong believer -- wrongly, I think -- in a very greedy-algorithm approach to code reuse issues. My first choice was to take the BSD 4.4-Lite release and make a kernel. I knew the code, I knew how to do it. It is now perfectly obvious to me that this would have succeeded splendidly and the world would be a very different place today. RMS wanted to work together with people from Berkeley on such an effort. Some of them were interested, but some seem to have been deliberately dragging their feet: and the reason now seems to be that they had the goal of spinning off BSDI. A GNU based on 4.4-Lite would undercut BSDI. So RMS said to himself, "Mach is a working kernel, 4.4-Lite is only partial, we will go with Mach." It was a decision which I strongly opposed. But ultimately it was not my decision to make, and I made the best go I could at working with Mach and doing something new from that standpoint. This was all way before Linux; we're talking 1991 or so." [1] http://www.groklaw.net/article.php?story=20050727225542530 http://www.groklaw.net/article.php?story=20050727225542530 [1]
    - dragonwriter 13y ago
      Note, in regard to Bushnell's quote, that "1991 or so" and "way before Linux" are contradictory. (Or, at least, require an strained definition of "way before"; Linux was first released in 1991.)
  - Sssnake 13y ago
    >the GNU tools are used in a huge number of operating systems You mean linux? That isn't a huge number. >and are installed on a staggering number of devices The staggering number of devices you refer to almost exclusively run busybox or one of the similar projects. GNU software is hugely bloated and not a good choice for embedded systems. >Second, it is debatable whether sticking to Hurd was a good or a bad idea technically No, it was fine technically. It had no developers and so nothing happened. Minix exists, obviously microkernels are possible.
- asveikau 13y ago
  Apple still insists on building their kernel atop Mach, and it doesn't seem to stop their momentum. (Even though it's kind of a strange choice.)
  - gillianseed 13y ago
    From what I understand, the Mach kernel which is now used in XNU is not the Mach micro kernel (3.0 >) but based upon the pre-micro-kernel 2.5 version of Mach. I'm not sure where I read this originally but I just googled this source which seems to back it up: http://www.roughlydrafted.com/0506.mk3.html http://www.roughlydrafted.com/0506.mk3.html
    - asveikau 13y ago
      I am not intimately familiar with the history of Mach, but what I do see is that in the late 80s and early 90s these two groups (NeXT and GNU) seeing Mach as the future (a position that makes no sense at a later time), and having vastly different outcomes. I don't know much about how these people work, but I always figured Mach at Apple is just about momentum and familiarity of contributors, rather than technology. NeXT hired Tevanian who worked on Mach at CMU, they spent roughly a decade hacking on Mach, then Apple did the same. I'd imagine they employ people who know Mach well and haven't seen it as worthwhile to replace it. I even remember they had this goofy project "MkLinux", which sought to put Linux in the position that BSD carries with XNU, on top of Mach... Just goofy stuff, unless you figure they had Mach hackers on staff.
    - empthought 13y ago
      According to the Apple docs XNU is based on Mach 3.0. https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/Mach/Mach.html https://developer.apple.com/library/mac/documentation/Darwin...
      - valleyer 13y ago
        That's misleading. Apple merged in a bunch of Mach 3 code but still maintains the architecture of Mach 2.5 (i.e., Mach + BSD both running in supervisor mode in one big monolith; no BSD server; xnu is not a microkernel…).
- gillianseed 13y ago
  Back when the choice was made, micro-kernels was all the rage in both academia and commercial ventures, and Stallman chose Mach since he thought it would speed up development, he was hardly alone in choosing Mach at this time, Apple (MkLinux, NeXTSTEP), IBM (Workplace OS) amongst others. He fully acknowledged that he made a mistake in going with Mach and as soon as Linux took off FSF focused on providing the necessary software to combine with Linux into an operating system and placed Hurd on 'life support', where it's been ever since.
  - maxlybbert 13y ago
    IIRC, ARPA at some point was more interested in funding projects based on Mach than based on any other kernel.
belorn 13y ago
I'm not sure that conversation is a good example of what you are trying to describe. Let's see if someone did the following things to the python project: 1#: Hire away the package maintainer. Then rather than continue and finish any current work, effectively remove that person from the community project. 2#: Redesign underlying structure of the project (like say, PyPy), but don't discuss any changes with the community. No PEPs, no discussion on mailing lists, no communication what so ever. 3#: Ignore current list of new feature being worked at. Community goals are unimportant. 4#: Add code regression! Do not care about maintaining performance. 5#: Demand that the changes get implemented immediately in next official release. Would anyone expect that to actually work today? Sure, Stallman could be more diplomatic and find (and succeed) with a middle ground solution, but the above steps are not how you join an ongoing software project.
- hamburglar 13y ago
  I tried to read that conversation in a neutral light, because I think RMS and JWZ are both kind of ... polarizing personalities, but RMS really came off as a stubborn, ineffective whiner in that whole thread. In particular "you hired away my maintainer" is a pathetic excuse for not releasing something for so long. Anybody could have hired away your maintainer, and you'd have to soldier on; it has no relevance that your maintainer went to a "competing" (in your territorial view) project. I also read the argument about the redesign of the event system and was pretty flabbergasted. The argument seems to reduce to "lucid emacs decided to design a proper event datatype because having an event be entirely represented by a simple integer keycode both lost information and made it impossible to represent certain keystrokes" versus "but ints are simple and backward compatible!"
  - lmm 13y ago
    Funny, I had the opposite view. I guess your opinion of the personalities really does change everything.
    - hamburglar 13y ago
      There is one (and only one) other possibility, which is that you and I both read the conversation with flawless objectivity, and that you are wrong. :D
revelation 13y ago
> I couldn't change the plans, so I had to make the best of them. I suggested a design to him, one oriented toward editing formatted text--a feature I wanted Emacs to have, eventually. Hah, 20 years in the making!
mempko 13y ago
the exchange made lucid seem like a bunch of assholes
- eropple 13y ago
  Care to explain? I thought that the Lucid guys made reasonable technical arguments (especially in light of, y'know, history, over the last twenty years) and that RMS was attempting to both grandstand and emotionally manipulate people into adopting his preferred position.

cpach 13y ago

I thought RMS had resigned as Emacs’ maintainer? http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02140.html http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg021...

hyperpape 13y ago
Maybe--but the tenor of the discussion strongly suggests, if not implies, that he makes the call about whether they can leave bzr.
dded 13y ago
One of the reasons I chose GNU Emacs over XEmacs was a feeling that GNU Emacs will be maintained, even advanced, for as long as RMS has the strength to type. It's his baby. (There were other reasons, the big one being momentum. XEmacs didn't run on the platform I was on for a long time, so it would have been a switch.)
- aaronem 13y ago
  An excellent point; for example, although I don't have any reason to think RMS himself did this, Emacs 24.4 will have file change notification support across all platforms where it compiles and where such notifications are available. I grant that's a somewhat overdue feature for Emacs to have (e.g., I've wanted it ever since I set up Dropbox to synchronize my org-mode files across all my boxes), but it's definitely evidence that Emacs isn't lacking of maintenance and improvement. I wonder: If Emacs rarely gains new features in core, is it because there aren't enough developers doing enough to improve it, or rather because people are having a hard time thinking up new features to add which Emacs doesn't already have?
  - agumonkey 13y ago
    Lisp systems legacy I suppose, the core is ~tiny, everything else is a library.
    - aaronem 13y ago

mathattack 13y ago

For better or worse, having a vision is a very different skillset from having the management skillset to make things happen. Sometimes people deride management when talking about the importance of vision and leadership. There is also the current trend of companies giving up managers entirely. RMS is a prime example of why management is an important skill. It is inefficient for him to do everything himself. It's also inefficient for him to chase people down for all the details. If he had a solid COO who understood his vision, his organization would be much more effective.

stiff 13y ago

I think this is more inertia than anything else. It is pretty obvious that Stallman isn't the easiest person to talk to, but he has consistently put huge amount of efforts into GNU for lots of years, and, whatever he did as the maintainer, seems to have worked out pretty much in the end. If there was anyone as active in the Emacs community today as Stallman was in his prime, they could easily push through changes despite Stallman's disagreement, via a fork or otherwise, but there isn't such a person, and that is that. Consider that it has been almost 30 years since GNU Emacs started, for most of this time RMS has been the maintainer, and GNU Emacs continues to this day to be the most advanced, popular and active Emacs there is, while the various forks in existence like XEmacs, SXEmacs lost steam pretty quickly. So it certainly hasn't been all bad on his side.

jedrek 13y ago
The popularity of a specific fork of Emacs is a moot point, it's the popularity of Emacs as an editor (or should I say, as a platform?) that is at issue. Stallman was active, how that he's not active he needs to either defer to people who are active or watch as fewer and fewer people take advantage of his work.
- stiff 13y ago
  Stallman doesn't have much influence on Emacs development itself anymore, but Emacs is a GNU project, Stallman is still the head of GNU, and a move to another VCS would be a major organizational change. I too wish he would be less hard-headed about this, but lets not overblow this issue out of proportion.
  - lstamour 13y ago
    In replies, he says he doesn't oppose the move to git. Most devs who've replied support git. There's already a mirror. Let's not make mountains out of molehills...
ams6110 13y ago
Over those 30 years the emacs codebase must have moved through several revision control systems. Why is moving to another one such a big deal?

chebucto 13y ago

As he said, 'more than Emacs is at stake here.'.[1] I presume this refers to Bazaar's status as part of the GNU project, and that RMS did not want to write off part of GNU without being certain he needed to. Regardless, he has since OKd the switch from bzr: I don't insist that Emacs should stay with bzr. I chose to support bzr because it was still a contender at the time. [2] [1] https://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00934.html https://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00... [2] https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00014.html https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00... edit: formatting

codereflection 13y ago
I think Stallman is being reasonable here.
- dredmorbius 13y ago
  He's not always an unreasonable man. https://paragraft.wordpress.com/2008/05/01/progress-and-the-unreasonable-man/ https://paragraft.wordpress.com/2008/05/01/progress-and-the-...
kro0ub 13y ago
I think the subsequent OK'ing is unfortunate. Attracting younger hackers shouldn't be a more important goal than integrity.
- secoif 13y ago
  What does this have to do with integrity?
  - kro0ub 13y ago
    I mean, don't not fixing what ain't broke is certainly a matter of integrity. Fixing something to the latest hippest new fad just to "attract young hackers" detracts from integrity. Making the editor an awesome badass attractive editor should be enough. Otherwise you'll only be attracting groupthink-prone douchebags, anyway.

malandrew 13y ago

"When questioned, he says that there's too much at stake to abandon bzr if it can be avoided at all." The big difference between then and now is that this time you have a very competent developer with an exceptional reputation offering to lead the migration. With esr leading things, there is a lot less at risk.

logjam 13y ago
So you're saying that ESR will do for Emacs what he did for...fetchmail.