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 communit…
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 yo…
Poaching the lead dev to work on your own fork is a hostile move, and in my book, it provides a reasonable excuse for the delays, since nobody was able to take his succession immediately.
The guys at Lucid also barely communicated for long periods of time, making collaboration impossible.
Among game developers, in particular, because of their need to have revision control for large assets, Mercurial seems to be more popular than git due to the large files extension. Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4.
Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4. Hence why I said "realistically, perforce or other solutions appear to be even more popular among that particular developer segment." My comment you quoted was comparing the popularity of Mercurial to Git, not p4. Also, I'd disagree with your assertion regarding "most devs in grown-up, professional shops". Microsoft's SourceSafe has a…
Are that many people really using SourceSafe still? TFS is now Microsoft's preferred solution, although I don't know what they use internally.
It seems that most .NET devs prefer something baked straight into Visual Studio and my experience has been that this is part of the problem in getting those teams to migrate to Git, which is most powerful from the command line. Personally, I greatly prefer my source control system to be separate from my development environment or IDE.
Git's pretty well baked straight into Visual Studio now that it's built into the latest version of Team Foundation Server. Mercurial's the one where you really want to be using it from the command line. It's had VS plugins, but they're all kind of janky by comparison.
Or use TortoiseHg or SourceTree, if you're not comfortable with the CLI. They both work great. Also, if you need to host 'your own github', try RhodeCode.
I hate when people say "git won the war", it sounds like an excuse to close minds and stop progress. What if "Microsoft won the war"? Or vim? Or IBM? Or Java? Or Taco Bell?
Microsoft did win the war; very little progress has been made by its competitors from the time; what's had success has been new OSes - OSX, iOS and Android (which while built of GNU/Linux pieces, is radically different from traditional GNU/Linux - enough to qualify as a different OS IMO, since the API is different). Vim did win the war; there's still nothing better. IBM did win the war, and then shot themselves in th…
> Vim did win the war; there's still nothing better
Not to mention his insistence on GNU Hurd being based on Mach, which pretty much ended up killing the project.
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…
>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.
> 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
the exchange made lucid seem like a bunch of assholes
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.
> "To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from" What? Of course you can. I've worked on teams that did it. You are talking total rubbish.
I'm a happy git user, but tell me how this is supposed to work: there's me and one other guy working on a project. There are three logical branches: trunk, his branch, and my branch. In SVN there would be five source trees: those three on the server, his working copy and my working copy. But in git we end up with fifteen: the three on the server, my branch on my machine, his branch on my machine, master on my machine…
Is there a reason you aren't using disposable feature branches?
I don't track my other developers' feature branches locally unless I need to view them.
>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?
I wonder if any of those guys would ever contribute to emacs anyway, unless we rewrite it in javascript.
SNARK: No need to rewrite it in Javascript. Just call it "Sublime Text 5" and charge them seventy bucks a copy.
Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4. Hence why I said "realistically, perforce or other solutions appear to be even more popular among that particular developer segment." My comment you quoted was comparing the popularity of Mercurial to Git, not p4. Also, I'd disagree with your assertion regarding "most devs in grown-up, professional shops". Microsoft's SourceSafe has a…
Are that many people really using SourceSafe still? TFS is now Microsoft's preferred solution, although I don't know what they use internally.
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 a…
> 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 respo…
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.)