4 ms·

The important take-away here isn't the relative merits of each DVCS, but that bzr is not used by anybody any more, and it is impeding the uptake of new contribu

by mickeyp 13y ago

The important take-away here isn't the relative merits of each DVCS, but that bzr is not used by anybody any more, and it is impeding the uptake of new contributors to Emacs.

rbanffy 13y ago
Compared to the decision (and ability) to contribute to Emacs, the choice of DVCS seems to be rather unimportant.
- mickeyp 13y ago
  Ten (edit: even five!) years ago I'd agree with you. Back then a source control system was a piece of software you used for keeping a versioned history of your work and to enable you to collaborate with coworkers or friends. It was a tool. Now? It's A Big Deal to a lot of younger developers. It is almost totemic. If it's not Git and (ideally) Github then.. it isn't worth hacking on?
  - joelthelion 13y ago
    >Now? It's A Big Deal to a lot of younger developers. It is almost totemic. If it's not Git and (ideally) Github then.. it isn't worth hacking on? Do you really want those guys on your project?
    - Goosey 13y ago
      Absolutely. Stigma over a (d)vcs !== (in)ability to contribute to a project.
    - sparkie 13y ago
      I wonder if any of those guys would ever contribute to emacs anyway, unless we rewrite it in javascript.
      - reddit_clone 13y ago
        You made me spill my coffee on the keyboard. It does seem Javascript people have taken over the obnoxious hipsterism from Ruby folks.
      - deleted 13y ago
        [deleted]
      - Crito 13y ago
        If the Emacs/Guile thing ever gets off the ground properly, ECMAScript/Emacs may become a possibility.
        rbanffy 13y ago
        But remember: it's not because it's possible that it's a good idea. ;-)
        deleted 13y ago
        [deleted]
      - aaronem 13y ago
        SNARK: No need to rewrite it in Javascript. Just call it "Sublime Text 5" and charge them seventy bucks a copy.
    - ecspike 13y ago
      Long answer yes with a but. They will eventually take up the mantle from devs who age out or die. We might have something totally different than Git at that point but it's not good to dismiss them either. That is how projects die.
    - rodgerd 13y ago
      Well, since they're constantly told on HN that unless they're visible on Github they aren't getting a job, why are you blaming them?
- aaronem 13y ago
  The impression I have is that bzr is just another roadblock between a potentially interested novice and a patch accepted into the Emacs source. (It's not by far the largest one, though, and while I think esr has a point, I also think it'd be of help for some of the current Emacs developers to publish a "How to start hacking Emacs" document, for the benefit of people like me who would love to contribute but who have absolutely no idea where or how to start.)
  - quotemstr 13y ago
    > help for some of the current Emacs developers to publish a "How to start hacking Emacs" documen 1. Find thing you don't like 2. M-x find-function RET function-to-fix RET 3. Hack hack hack (use C-M-x or M-x eval-buffer liberally; also, read about edebug) 4. Make diff relative to Emacs base code 5. Send diff to bug-gnu-emacs@gnu.org What I love about hacking on Emacs is that it's so easy to find the bit of code responsible for a given feature and hack on that code in a running editor. There's nothing like it. If I'm using Firefox and don't like the address bar, I need to go dig through XUL, find the thing I don't like, and restart Firefox. Emacs? You just find the function and edit it right in the editor.
    - aaronem 13y ago
      Thank you, yes, it's not so much finding the code I need to modify that's the problem, as understanding how any given single thing fits into the Emacs C source as a whole. Hacking the Lisp side I don't really have a problem with -- but if I want to, for example, extend the MESSAGE primitive so that it can check a list of messages not to emit in the minibuffer, things get very hairy, very fast. A general overview of what's what, and where, in the C source, would be extremely useful, and I haven't had much luck finding anything like that in the source distribution or online. (And, yes, I have read etc/CONTRIBUTE, etc/DEBUG, and (Info)Elisp/GNU Emacs Internals/*. And I'm pretty sure doing what I'm talking about doing to MESSAGE would be a bad idea, because it'd require a call up into Lisp space every time the primitive gets called, which can be extremely frequent especially during initialization. But I know somebody who'd like to have that functionality available, and it seemed like a relatively simple place to start, until I tried actually doing it.)
- davidw 13y ago
  For core work, it's probably not that important. For trivial patches, it's probably kind of a pain in the neck. But a lot of people start with a small patch, so it's best to encourage them by making it easy.
- wirrbel 13y ago
  For me, I know to use subversion and git to a degree that I am really comfortable with (from the two I stronly prefer git). Another VCS means that I have to take a few leaps, new commands, subtle to extreme differences in workflow as well as different names for the same things. So a VCS that is well-known by people will (on average) make contributing more convenient to the average potential contributor. After diving into Emacs' codebase, changing or tweaking a few things that bug me, there are a few walls to climb when actually contributing those changes. I.e. cleaning up the code, creating a patch/pull request, outlining changes and intentions, etc. An unfamiliar VCS adds another burden to the contributor. Remember that we are not talking about people who are paid for diving into their employer's VCS but about people who primarily work on other projects.
- rcthompson 13y ago
  With a repository the size of Emacs, it matters. Look at some of the other comments on this article here on HN, where people note that trivial bzr commands on the Emacs repo take way too long to run.
- vidarh 13y ago
  It's about lowering the threshold so that when I need to patch your project, I can trivially clone the repo with software I already have installed and know, do my change, commit and create a patch or submit a pull request to Github or whatever with so little extra hassle that I feel compelled to do so rather than just making the change to my local tar-ball and never upstreaming the changes unless/until there's something large enough to be a pain to maintain separately. Frankly, that ability is more important than the choice of DVCS: There's more value from most people standardising than in picking the "optimal" DVCS just because of the lowered barriers to participation.
chongli 13y ago
I never would have guessed. Pretty much all of the interaction I have with Emacs contributors is through packages on github. Emacs lisp is so ubiquitous and useful that it doesn't really make much sense to include most things in Emacs itself.

by mickeyp 13y ago

The important take-away here isn't the relative merits of each DVCS, but that bzr is not used by anybody any more, and it is impeding the uptake of new contributors to Emacs.

rbanffy 13y ago

Compared to the decision (and ability) to contribute to Emacs, the choice of DVCS seems to be rather unimportant.

mickeyp 13y ago
Ten (edit: even five!) years ago I'd agree with you. Back then a source control system was a piece of software you used for keeping a versioned history of your work and to enable you to collaborate with coworkers or friends. It was a tool. Now? It's A Big Deal to a lot of younger developers. It is almost totemic. If it's not Git and (ideally) Github then.. it isn't worth hacking on?
- joelthelion 13y ago
  >Now? It's A Big Deal to a lot of younger developers. It is almost totemic. If it's not Git and (ideally) Github then.. it isn't worth hacking on? Do you really want those guys on your project?
  - Goosey 13y ago
    Absolutely. Stigma over a (d)vcs !== (in)ability to contribute to a project.
  - sparkie 13y ago
    I wonder if any of those guys would ever contribute to emacs anyway, unless we rewrite it in javascript.
    - reddit_clone 13y ago
      You made me spill my coffee on the keyboard. It does seem Javascript people have taken over the obnoxious hipsterism from Ruby folks.
    - deleted 13y ago
      [deleted]
    - Crito 13y ago
      If the Emacs/Guile thing ever gets off the ground properly, ECMAScript/Emacs may become a possibility.
      - rbanffy 13y ago
        But remember: it's not because it's possible that it's a good idea. ;-)
      - deleted 13y ago
        [deleted]
    - aaronem 13y ago
      SNARK: No need to rewrite it in Javascript. Just call it "Sublime Text 5" and charge them seventy bucks a copy.
  - ecspike 13y ago
    Long answer yes with a but. They will eventually take up the mantle from devs who age out or die. We might have something totally different than Git at that point but it's not good to dismiss them either. That is how projects die.
  - rodgerd 13y ago
    Well, since they're constantly told on HN that unless they're visible on Github they aren't getting a job, why are you blaming them?
aaronem 13y ago
The impression I have is that bzr is just another roadblock between a potentially interested novice and a patch accepted into the Emacs source. (It's not by far the largest one, though, and while I think esr has a point, I also think it'd be of help for some of the current Emacs developers to publish a "How to start hacking Emacs" document, for the benefit of people like me who would love to contribute but who have absolutely no idea where or how to start.)
- quotemstr 13y ago
  > help for some of the current Emacs developers to publish a "How to start hacking Emacs" documen 1. Find thing you don't like 2. M-x find-function RET function-to-fix RET 3. Hack hack hack (use C-M-x or M-x eval-buffer liberally; also, read about edebug) 4. Make diff relative to Emacs base code 5. Send diff to bug-gnu-emacs@gnu.org What I love about hacking on Emacs is that it's so easy to find the bit of code responsible for a given feature and hack on that code in a running editor. There's nothing like it. If I'm using Firefox and don't like the address bar, I need to go dig through XUL, find the thing I don't like, and restart Firefox. Emacs? You just find the function and edit it right in the editor.
  - aaronem 13y ago
    Thank you, yes, it's not so much finding the code I need to modify that's the problem, as understanding how any given single thing fits into the Emacs C source as a whole. Hacking the Lisp side I don't really have a problem with -- but if I want to, for example, extend the MESSAGE primitive so that it can check a list of messages not to emit in the minibuffer, things get very hairy, very fast. A general overview of what's what, and where, in the C source, would be extremely useful, and I haven't had much luck finding anything like that in the source distribution or online. (And, yes, I have read etc/CONTRIBUTE, etc/DEBUG, and (Info)Elisp/GNU Emacs Internals/*. And I'm pretty sure doing what I'm talking about doing to MESSAGE would be a bad idea, because it'd require a call up into Lisp space every time the primitive gets called, which can be extremely frequent especially during initialization. But I know somebody who'd like to have that functionality available, and it seemed like a relatively simple place to start, until I tried actually doing it.)
davidw 13y ago
For core work, it's probably not that important. For trivial patches, it's probably kind of a pain in the neck. But a lot of people start with a small patch, so it's best to encourage them by making it easy.
wirrbel 13y ago
For me, I know to use subversion and git to a degree that I am really comfortable with (from the two I stronly prefer git). Another VCS means that I have to take a few leaps, new commands, subtle to extreme differences in workflow as well as different names for the same things. So a VCS that is well-known by people will (on average) make contributing more convenient to the average potential contributor. After diving into Emacs' codebase, changing or tweaking a few things that bug me, there are a few walls to climb when actually contributing those changes. I.e. cleaning up the code, creating a patch/pull request, outlining changes and intentions, etc. An unfamiliar VCS adds another burden to the contributor. Remember that we are not talking about people who are paid for diving into their employer's VCS but about people who primarily work on other projects.
rcthompson 13y ago
With a repository the size of Emacs, it matters. Look at some of the other comments on this article here on HN, where people note that trivial bzr commands on the Emacs repo take way too long to run.
vidarh 13y ago
It's about lowering the threshold so that when I need to patch your project, I can trivially clone the repo with software I already have installed and know, do my change, commit and create a patch or submit a pull request to Github or whatever with so little extra hassle that I feel compelled to do so rather than just making the change to my local tar-ball and never upstreaming the changes unless/until there's something large enough to be a pain to maintain separately. Frankly, that ability is more important than the choice of DVCS: There's more value from most people standardising than in picking the "optimal" DVCS just because of the lowered barriers to participation.

chongli 13y ago

I never would have guessed. Pretty much all of the interaction I have with Emacs contributors is through packages on github. Emacs lisp is so ubiquitous and useful that it doesn't really make much sense to include most things in Emacs itself.