* What a modern collaboration toolkit looks like @ 2007-12-30 12:22 Eric S. Raymond 2007-12-30 15:32 ` Thien-Thi Nguyen ` (4 more replies) 0 siblings, 5 replies; 258+ messages in thread From: Eric S. Raymond @ 2007-12-30 12:22 UTC (permalink / raw) To: emacs-devel This started out as part of a longer essay called "On not kissing the pig". But that essay grew into an epic. Rather than dump it on the list all at once, I think it will be useful if I start by giving everybody a clear idea of the potential benefits of changing our practices. I'm going to describe the collaboration toolkit on another project where I happen to be a senior dev, called Battle For Wesnoth. You can find the project at <http://www.wesnoth.org/>. This is a typical modern open-source project. It's not even a particularly large one -- no more than a dozen core devs, 58 developers total. Here are the collaborative tools we use every day: * Source control with Subversion * A bug tracker * A very active IRC channel used for routine dev chatter * A dev mailing list, used mostly for white papers and long proposals * Web forums where a large user community hangs out * Subversion commits are echoed to IRC in real time by a monitor bot * Subversion commits that reference a bug append a comment to the tracker * A bot on IRC that you can query with a bug number and get a tracker URL. Here are some of the ways my workflow on Wesnoth differs from my workflow on Emacs: 1. When I do a commit of changes to several files, the entire changeset is saved as a unit with a single change comment attached to it. a) That change can be referenced, through its Subversion revision ID. (So, for example, "Hey boucman, your r22615 broke linger mode!") b) That change can be backed out as a unit. c) That change is instantly browseable by any dev. d) If that change is a fix that references a bug number, that fact instantly becomes part of the bug database *where everyone can see it*. 2. My commit is also echoed to the IRC channel, where there are almost never fewer than three or four devs hanging out as they hack, chatting in real time. Review tends to happen instantly. 3. Because everybody (and our user community!) uses the bug tracker, everybody always knows exactly what the dozen most important bugs are, and has a pretty good idea what the dozen most valuable feature requests are. 4. Because the IRC has a monitor bot hooked to the bug database, whenever someone says "Eric, have you looked at feature request #2355, it looks like your kind of thing." I can get to that issue by typing "wesbot: bug #2355" and clicking once. Questioner usually gets a response less than 30 seconds later. If I address the request, they'll see my commit comment in real time without me having to do anything special. 5. The entire commit history of the project is visible to me moments after I type C-X v l. This is much more powerful than just having the per-file change history visible, because the commit groupings themselves tell me valuable things about developer intentions. The effect of all these tools is more than the sum of its parts. One huge one is simply that devs can choose to spend time picking bugs off the tracker and nailing them, with basically zero process friction. Another is that we routinely hash out serious design and coding issues in real time, because everyone on the chat channel can share hyperlinks to the codebase, the commit history, the bug tracker, and posts on the user forums. Yet a third is that when we decide to do it, we can converge on a releasable state with almost absurd ease. Like, Ivanovic (our release manager) will announce "Point release scheduled this coming Wednesday" and everyone will pretty much flip into bug-stomping mode. The tracker bug list tends to shrink dramatically when this happens -- not only do we get prepared for release but *we know we've done so*. More generally, development happens *fast*. I don't have to wait weeks to find out whether other devs think of an idea. Commonly I know within minutes. The Wesnoth devs are good but not exceptionally so, and we're weighed down by a crappy implementation language (C++). Nevertheless our productivity, in terms of goals achieved per hour of work, is quite high. That's because our collaboration tools support everything we do without imposing noticeable process friction. This makes us dramatically more effective as individuals and as a group than we could possibly be without them. Lessons for the Emacs project? Hell, yes. But I'm not going to write that rant until y'all have had a little time to absorb this description of how things can be. And bear in mind: At the end of 2007 this is obervably *normal*. It's not that Battle For Wesnoth's collaboration toolkit is ahead of the curve -- it's that Emacs's is behind. Way, *way* behind. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> Americans have the will to resist because you have weapons. If you don't have a gun, freedom of speech has no power. -- Yoshimi Ishikawa, Japanese author, in the LA Times 15 Oct 1992 ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-30 12:22 What a modern collaboration toolkit looks like Eric S. Raymond @ 2007-12-30 15:32 ` Thien-Thi Nguyen 2007-12-30 15:42 ` Richard Stallman ` (3 subsequent siblings) 4 siblings, 0 replies; 258+ messages in thread From: Thien-Thi Nguyen @ 2007-12-30 15:32 UTC (permalink / raw) To: Eric S. Raymond; +Cc: emacs-devel () "Eric S. Raymond" <esr@snark.thyrsus.com> () Sun, 30 Dec 2007 07:22:17 -0500 (EST) And bear in mind: At the end of 2007 this is obervably *normal*. It's not that Battle For Wesnoth's collaboration toolkit is ahead of the curve -- it's that Emacs's is behind. Way, *way* behind. interesting stuff! i'm worried about speedfreak mentality, however. how does the group treat (not (connected-p 'always)) programmers? more precisely: what kind of stigmatism do such programmers endure? thi ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-30 12:22 What a modern collaboration toolkit looks like Eric S. Raymond 2007-12-30 15:32 ` Thien-Thi Nguyen @ 2007-12-30 15:42 ` Richard Stallman 2007-12-30 17:22 ` Eric S. Raymond 2007-12-31 4:31 ` Eli Zaretskii ` (2 subsequent siblings) 4 siblings, 1 reply; 258+ messages in thread From: Richard Stallman @ 2007-12-30 15:42 UTC (permalink / raw) To: Eric S. Raymond; +Cc: emacs-devel I usually don't have an internet connection, so I could not possibly use the methods you recommend. I cannot communicate with people by IRC. I cannot get information from a web interface. Email and CVS work for me because I have the data off-line. Even when I have a net connection, IRC is inefficient in terms of my time. I cannot afford watch a window while text dribbles in. I want to get the information as a batch, such as an email message. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-30 15:42 ` Richard Stallman @ 2007-12-30 17:22 ` Eric S. Raymond 2007-12-30 20:25 ` Robert J. Chassell ` (2 more replies) 0 siblings, 3 replies; 258+ messages in thread From: Eric S. Raymond @ 2007-12-30 17:22 UTC (permalink / raw) To: Richard Stallman; +Cc: Eric S. Raymond, emacs-devel Richard Stallman <rms@gnu.org>: > I usually don't have an internet connection, so I could not possibly > use the methods you recommend. I cannot communicate with people by > IRC. I cannot get information from a web interface. Er...perhaps you should fix these problems, rather than allowing them to limit and damage Emacs and every other project you are involved in. How is it even *possible* that you cannot get information from a Web interface? -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-30 17:22 ` Eric S. Raymond @ 2007-12-30 20:25 ` Robert J. Chassell 2007-12-30 21:55 ` Nick Roberts 2007-12-30 22:58 ` Richard Stallman 2 siblings, 0 replies; 258+ messages in thread From: Robert J. Chassell @ 2007-12-30 20:25 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org>: > I usually don't have an internet connection, so I could not possibly > use the methods you recommend. I cannot communicate with people by > IRC. I cannot get information from a web interface. "Eric S. Raymond" <esr@thyrsus.com>: Er...perhaps you should fix these problems, rather than allowing them to limit and damage Emacs and every other project you are involved in. Why should RMS change his politics or his procedures? As for myself, I cannot have a continuous Internet connection, for example when I am visiting. Moreover, I certainly don't want one at home because (a) although I have a great deal of security I am not an expert and I don't trust that I won't run into a malicious external site, and (b) I want to get work done and not be interrupted. I know there are people who do not mind interruptions, but I am not one of them. For me, that is key. Different people have different desires. An advantage of email is that you don't have to respond for a day or two. -- Robert J. Chassell GnuPG Key ID: 004B4AC8 bob@rattlesnake.com bob@gnu.org http://www.rattlesnake.com http://www.teak.cc ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-30 17:22 ` Eric S. Raymond 2007-12-30 20:25 ` Robert J. Chassell @ 2007-12-30 21:55 ` Nick Roberts 2007-12-30 22:25 ` Lennart Borgman (gmail) 2007-12-30 22:58 ` Richard Stallman 2 siblings, 1 reply; 258+ messages in thread From: Nick Roberts @ 2007-12-30 21:55 UTC (permalink / raw) To: esr; +Cc: Eric S. Raymond, Richard Stallman, emacs-devel > > I usually don't have an internet connection, so I could not possibly > > use the methods you recommend. I cannot communicate with people by > > IRC. I cannot get information from a web interface. > > Er...perhaps you should fix these problems, rather than allowing them > to limit and damage Emacs and every other project you are involved in. I don't think Richard perceives it as a problem. After a long thread about using a bug tracker, we still use a file called FOR-RELEASE; seven months after 22.1 was released, there has been no bugfix 22.2 release; and after five and a half years on a branch, Unicode Emacs is still on a branch. This is how Emacs development works. As they say, you can lead a horse to water but you can't make it drink. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-30 21:55 ` Nick Roberts @ 2007-12-30 22:25 ` Lennart Borgman (gmail) 2007-12-30 22:58 ` Richard Stallman 0 siblings, 1 reply; 258+ messages in thread From: Lennart Borgman (gmail) @ 2007-12-30 22:25 UTC (permalink / raw) To: Nick Roberts; +Cc: esr, Eric S. Raymond, Richard Stallman, emacs-devel Nick Roberts wrote: > > > I usually don't have an internet connection, so I could not possibly > > > use the methods you recommend. I cannot communicate with people by > > > IRC. I cannot get information from a web interface. > > > > Er...perhaps you should fix these problems, rather than allowing them > > to limit and damage Emacs and every other project you are involved in. > > I don't think Richard perceives it as a problem. After a long thread about > using a bug tracker, we still use a file called FOR-RELEASE; seven months > after 22.1 was released, there has been no bugfix 22.2 release; and after > five and a half years on a branch, Unicode Emacs is still on a branch. > > This is how Emacs development works. As they say, you can lead a horse to > water but you can't make it drink. What was the problem with choosing a bug tracking system? Aren't there any systems where you can commit changes and do other things with bug track records just as you do for source code? ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-30 22:25 ` Lennart Borgman (gmail) @ 2007-12-30 22:58 ` Richard Stallman 0 siblings, 0 replies; 258+ messages in thread From: Richard Stallman @ 2007-12-30 22:58 UTC (permalink / raw) To: Lennart Borgman (gmail); +Cc: esr, esr, nickrob, emacs-devel What was the problem with choosing a bug tracking system? Aren't there any systems where you can commit changes and do other things with bug track records just as you do for source code? I would not be averse to using a bug-tracking system if I can operate it by mail. However, I don't think that recording the known bugs differently will automatically convince people to work on fixing them. That's the bottleneck. The same 4 or 5 bugs have been recorded in the Emacs 22 FOR-RELEASE file for over a month. Would people please work on fixing them? ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-30 17:22 ` Eric S. Raymond 2007-12-30 20:25 ` Robert J. Chassell 2007-12-30 21:55 ` Nick Roberts @ 2007-12-30 22:58 ` Richard Stallman 2007-12-31 2:58 ` Eric S. Raymond 2 siblings, 1 reply; 258+ messages in thread From: Richard Stallman @ 2007-12-30 22:58 UTC (permalink / raw) To: esr; +Cc: esr, emacs-devel > I usually don't have an internet connection, so I could not possibly > use the methods you recommend. I cannot communicate with people by > IRC. I cannot get information from a web interface. Er...perhaps you should fix these problems, rather than allowing them to limit and damage Emacs and every other project you are involved in. I will not turn my life upside down to follow your recommendations for development tools. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-30 22:58 ` Richard Stallman @ 2007-12-31 2:58 ` Eric S. Raymond 2007-12-31 12:14 ` Thien-Thi Nguyen 2007-12-31 22:29 ` Richard Stallman 0 siblings, 2 replies; 258+ messages in thread From: Eric S. Raymond @ 2007-12-31 2:58 UTC (permalink / raw) To: Richard Stallman; +Cc: esr, emacs-devel Richard Stallman <rms@gnu.org>: > > I usually don't have an internet connection, so I could not possibly > > use the methods you recommend. I cannot communicate with people by > > IRC. I cannot get information from a web interface. > > Er...perhaps you should fix these problems, rather than allowing them > to limit and damage Emacs and every other project you are involved in. > > I will not turn my life upside down to follow your recommendations for > development tools. It's not the fact that they're my recommendations that is relevant. Don't turn this into a personality issue, it's not one. It's a question about how your choices affect the projects you are responsible for. *You* are talented enough that you can out-code most other people even when they have modern tools and you're refusing them. But this isn't true of most of your contributors -- by imposing your limits on their working methods as well as your own you're putting the projects you run under a severe handicap, damaging their ability to ship timely and high-quality code. Telling evidence for this is the very long interval between Emacs point releases and the trouble you have been having clearing your bug list. In 1997 the Emacs project's performance on these scores would have been well within the normal range, given the number and quality of developers you have -- but the world has changed, the tools are better, the typical tempo of development is faster, and in 2007 this project's performance looks really bad. Unpredictable intervals of more than a year between point releases just do not cut it these days. Here's a scale indication: Battle For Wesnoth does a point release pretty regularly every three weeks, and they're usually good releases. This is by no means exceptional performance in 2007. With decent tools and practices I'm sure we could match it. Very unfortunately, the second-order effects of poor productivity may be worse than the first-order ones. Many younger developers out there think Emacs is limping along on old ideas and old tech, its glory days long in the past. I think they're seriously wrong, because...well...I think Lisp is eternal; earlier this very evening at a holiday party I was defending Emacs against a bunch of Eclipse fans who think I'm nuts to hold onto it. But it gets harder to maintain that position as time goes by. When those Eclipse fans pointed and laughed because we're still stuck on CVS and don't have a bug tracker, what counter could I have had? They know these are bad choices and they know that I know it -- so when they write off Emacs as old, tired, and irrelevant to anything they're interested in, I find it increasingly difficult to reply. Emacs will never be irrelevant for *me*; it fits my hand too well. But a thing I was painfully reminded of just a few hours ago is that we're losing the kids (for values of "kids" up to about age 35). That means we're losing the future. And that's why, when you block your projects from using modern tools, it's a serious problem. I certainly don't expect you to "turn your life upside down" to meet my preferences -- but if you're not willing to do it so the projects that have been your life's work will remain able to attract new blood and have a healthy future, that's entirely another matter. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 2:58 ` Eric S. Raymond @ 2007-12-31 12:14 ` Thien-Thi Nguyen 2008-01-01 23:57 ` John S. Yates, Jr. 2007-12-31 22:29 ` Richard Stallman 1 sibling, 1 reply; 258+ messages in thread From: Thien-Thi Nguyen @ 2007-12-31 12:14 UTC (permalink / raw) To: emacs-devel () "Eric S. Raymond" <esr@thyrsus.com> () Sun, 30 Dec 2007 21:58:36 -0500 block your projects from using modern tools i did not see where rms says he intends to block anything, just that he is not willing to do non-email-based hacking. (i take that as a personal statement, as one hacker's preference amongst the group, and a reasonable position to hold.) you can save yourself the rant and try to think of a way to accomodate email-based hacking w/ speedfreak hacking. as for the "kids" missing out -- let them spin. what they chase they will find in emacs, sooner or later. perhaps it will not be in /usr/bin/emacs, but instead some .../embedded-emacs-workalike.so; that's irrelevant. thi ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 12:14 ` Thien-Thi Nguyen @ 2008-01-01 23:57 ` John S. Yates, Jr. 2008-01-02 1:46 ` Thien-Thi Nguyen 0 siblings, 1 reply; 258+ messages in thread From: John S. Yates, Jr. @ 2008-01-01 23:57 UTC (permalink / raw) To: Thien-Thi Nguyen; +Cc: emacs-devel On Mon, 31 Dec 2007 13:14:02 +0100, Thien-Thi Nguyen wrote: >i did not see where rms says he intends to block anything, >just that he is not willing to do non-email-based hacking. The bzr project has an impressive amount of tooling to support email-based development. For starters, take a look at its send command: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#send and the BundleBuggy tool: http://bazaar-vcs.org/BundleBuggy?highlight=%28bundle%29 /john ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 23:57 ` John S. Yates, Jr. @ 2008-01-02 1:46 ` Thien-Thi Nguyen 0 siblings, 0 replies; 258+ messages in thread From: Thien-Thi Nguyen @ 2008-01-02 1:46 UTC (permalink / raw) To: John S. Yates, Jr.; +Cc: emacs-devel () "John S. Yates, Jr." <john@yates-sheets.org> () Tue, 01 Jan 2008 18:57:18 -0500 The bzr project has an impressive amount of tooling to support email-based development. For starters, take a look at [some bzr features] thanks for the tip. maybe i'll get to looking into bzr sometime in 2008. i am in the midst of a (now) two-month trial-by-fire period w/ git. it's interesting. some side effects can be seen at: <http://www.gnuvola.org/wip/>. i think long term what will win is some distributed system, presuming the off{line,world ;-} folks and cortical jackers can maintain mutual respect. thi ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 2:58 ` Eric S. Raymond 2007-12-31 12:14 ` Thien-Thi Nguyen @ 2007-12-31 22:29 ` Richard Stallman 2008-01-01 0:19 ` Leo 1 sibling, 1 reply; 258+ messages in thread From: Richard Stallman @ 2007-12-31 22:29 UTC (permalink / raw) To: esr; +Cc: esr, emacs-devel And that's why, when you block your projects from using modern tools, it's a serious problem. If it is a problem (and other people seem to disagree with you on this), it can't be helped. I won't change the way I live my life just so I can use different methods to work on Emacs Working on Emacs is not all I do. Meanwhile, using IRC for discussions would be very inefficient for me, so I won't do that even when I do have a net connection. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 22:29 ` Richard Stallman @ 2008-01-01 0:19 ` Leo 0 siblings, 0 replies; 258+ messages in thread From: Leo @ 2008-01-01 0:19 UTC (permalink / raw) To: emacs-devel On 2007-12-31 22:29 +0000, Richard Stallman wrote: > And that's why, when you block your projects from using modern tools, > it's a serious problem. > > If it is a problem (and other people seem to disagree with you on > this), it can't be helped. I don't think other people disagree with ESR. I think people understand how difficult it is to propose such a solution. I really appreciate ERS's effort to save the Emacs project. -- .: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :. Use the best OS -- http://www.fedoraproject.org/ ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-30 12:22 What a modern collaboration toolkit looks like Eric S. Raymond 2007-12-30 15:32 ` Thien-Thi Nguyen 2007-12-30 15:42 ` Richard Stallman @ 2007-12-31 4:31 ` Eli Zaretskii 2007-12-31 13:07 ` Eric S. Raymond 2007-12-31 13:11 ` Alan Mackenzie 2008-01-19 17:45 ` Jari Aalto 4 siblings, 1 reply; 258+ messages in thread From: Eli Zaretskii @ 2007-12-31 4:31 UTC (permalink / raw) To: Eric S. Raymond; +Cc: emacs-devel > From: "Eric S. Raymond" <esr@snark.thyrsus.com> > Date: Sun, 30 Dec 2007 07:22:17 -0500 (EST) > > This is a typical modern open-source project. It's not even a > particularly large one -- no more than a dozen core devs, 58 > developers total. A striking difference with Emacs. We never had such a large group of active developers. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 4:31 ` Eli Zaretskii @ 2007-12-31 13:07 ` Eric S. Raymond 2007-12-31 20:57 ` Eli Zaretskii 2008-01-01 17:11 ` Alan Mackenzie 0 siblings, 2 replies; 258+ messages in thread From: Eric S. Raymond @ 2007-12-31 13:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Eric S. Raymond, emacs-devel Eli Zaretskii <eliz@gnu.org>: > > This is a typical modern open-source project. It's not even a > > particularly large one -- no more than a dozen core devs, 58 > > developers total. > > A striking difference with Emacs. We never had such a large group of > active developers. Really? How interesting. Makes me proportionately more important to Emacs than I thought I was. :-) The old-timers on this list should be asking themselves why, when Emacs is so undeniably important, it can't attract as many developers as a mere fantasy game. One of the ways the hacker community has changed as it has grown is that project populations are rather larger on average than they used to be. I see this as a direct effect of sites like SourceForge, Berlios, Gna!, Savannah, etc. which make it easier to coordinare larger dev groups. The Emacs project, though, is still operating at a scale and tempo I think of as being typical of the late 1980s and early 1990s. I think we are limited by poor tools, and by habits of thought derived from those poor tools. I'd like to help that change. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 13:07 ` Eric S. Raymond @ 2007-12-31 20:57 ` Eli Zaretskii 2007-12-31 21:41 ` Eric S. Raymond 2008-01-01 11:28 ` Tassilo Horn 2008-01-01 17:11 ` Alan Mackenzie 1 sibling, 2 replies; 258+ messages in thread From: Eli Zaretskii @ 2007-12-31 20:57 UTC (permalink / raw) To: esr; +Cc: esr, emacs-devel > Date: Mon, 31 Dec 2007 08:07:12 -0500 > From: "Eric S. Raymond" <esr@thyrsus.com> > Cc: "Eric S. Raymond" <esr@snark.thyrsus.com>, emacs-devel@gnu.org > > Eli Zaretskii <eliz@gnu.org>: > > > This is a typical modern open-source project. It's not even a > > > particularly large one -- no more than a dozen core devs, 58 > > > developers total. > > > > A striking difference with Emacs. We never had such a large group of > > active developers. > > Really? How interesting. Makes me proportionately more important to > Emacs than I thought I was. :-) I knew there was a compliment there somewhere... > The old-timers on this list should be asking themselves why, when Emacs > is so undeniably important, it can't attract as many developers as a > mere fantasy game. That's not a question for me. It's quite clear to me why programming a game would be more fun than programming a text editor. And if you are hinting that using CVS is the reason, then I must say that in the 15 years I've been involved in Emacs development (using RCS at first, btw), I don't think I've ever heard some potential contributor say that she refuses to come on board because of the VCS we use. Maybe my memory is failing me, who knows. > The Emacs project, though, is still operating at a scale and tempo I > think of as being typical of the late 1980s and early 1990s. I think > we are limited by poor tools, and by habits of thought derived from > those poor tools. My analysis is different: I think we are limited by a small number of core developers, and by the lack of head maintainer(s) who could devote much more time than any of us can evidently provide to coding and leading the rest of the developers. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 20:57 ` Eli Zaretskii @ 2007-12-31 21:41 ` Eric S. Raymond 2007-12-31 23:00 ` Nick Roberts ` (2 more replies) 2008-01-01 11:28 ` Tassilo Horn 1 sibling, 3 replies; 258+ messages in thread From: Eric S. Raymond @ 2007-12-31 21:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, emacs-devel Eli Zaretskii <eliz@gnu.org>: > And if you are hinting that using CVS is the reason, Not exactly. I think CVS in itself is *a* reason people sheer away from the project -- selecting themselves out before you even notice they're doing that -- but I think CVS is more important as a major symptom and part-cause of the largest problem this project has. That largest problem? Boy howdy, did I get a faceful of it last night at my friends the Matuszeks' post-Yule party. They're AI researchers and their parties attract a rather dizzying assortment of alpha geeks, considering we're in Pennsylvania. People fly in to be at their annual bash. I proudly mentioned my work on VC-mode, and got majorly dumped on for bothering with Emacs at all. The kids out there think we're a stagnant backwater, an old-boys club of bearded grognards that has learned nothing and forgotten nothing for the last decade. I'll also say I wasn't all that surprised at this reaction. I've seen this image problem building for a while; it's just that before I rejoined the dev team I had little incentive to address it. > > The Emacs project, though, is still operating at a scale and tempo I > > think of as being typical of the late 1980s and early 1990s. I think > > we are limited by poor tools, and by habits of thought derived from > > those poor tools. > > My analysis is different: I think we are limited by a small number of > core developers, and by the lack of head maintainer(s) who could > devote much more time than any of us can evidently provide to coding > and leading the rest of the developers. I don't disagree with you that either is a serious problem. But I see all three issues (few developers, weak leadership, crappy tools) as all causally linked and feeding into each other. In particular, crappy tools and weak leadership hinder attracting new developers. I can't solve the weak leadership problem, so I'm focusing on what I know how to do: fix the tools. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 21:41 ` Eric S. Raymond @ 2007-12-31 23:00 ` Nick Roberts 2008-01-01 0:50 ` Eric S. Raymond 2007-12-31 23:12 ` Eli Zaretskii 2008-01-01 0:10 ` Miles Bader 2 siblings, 1 reply; 258+ messages in thread From: Nick Roberts @ 2007-12-31 23:00 UTC (permalink / raw) To: esr; +Cc: esr, Eli Zaretskii, emacs-devel > In particular, crappy tools and weak leadership hinder attracting new > developers. I can't solve the weak leadership problem, so I'm > focusing on what I know how to do: fix the tools. Stating that Emacs has weak leadership is a ridiculous assertion as it's a highly successful project by any standards. I do agree, however, that it's going through a slow and painful death. Richard has already stated that he would like to hand over maintenance to one person or a small team. Currently you're not offering much more than rhetoric. If you volunteered to maintain Emacs over the next five years, say, now that might be an interesting propsition. Contrary to your suggestions, there are some very talented developers on this list, and they could probably cover areas of Emacs with which you are not familiar. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 23:00 ` Nick Roberts @ 2008-01-01 0:50 ` Eric S. Raymond 2008-01-01 4:22 ` Eli Zaretskii 0 siblings, 1 reply; 258+ messages in thread From: Eric S. Raymond @ 2008-01-01 0:50 UTC (permalink / raw) To: Nick Roberts; +Cc: esr, Eli Zaretskii, emacs-devel Nick Roberts <nickrob@snap.net.nz>: > Stating that Emacs has weak leadership is a ridiculous assertion as it's > a highly successful project by any standards. The "weak leadership" characterization was Eli's, not mine. I agree with it, however; Richard has been distracted and operating under some fairly crippling constraints. > Richard has already stated that he would like to hand over > maintenance to one person or a small team. Currently you're not > offering much more than rhetoric. If you volunteered to maintain > Emacs over the next five years, say, now that might be an > interesting propsition. Alas, I can't do that. But I have already offered to put in the full-time effort required to clean up the tools situation in 2008. This would, among other things, free the actual project lead to think about the right direction for Emacs itself. > Contrary to your suggestions, there are some very talented developers on this > list, and they could probably cover areas of Emacs with which you are not > familiar. Eh? When did I ever suggest the developers here weren't "very talented"? I believe I've actually said twice that they average more capable than at Battle For Wesnoth, which is the model I've been exhibiting for good tool use. There is no shortage of talent here. I'd say some of us have become rather too rigid in our thinking, but that's a different issue. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 0:50 ` Eric S. Raymond @ 2008-01-01 4:22 ` Eli Zaretskii 2008-01-01 6:20 ` Eric S. Raymond 0 siblings, 1 reply; 258+ messages in thread From: Eli Zaretskii @ 2008-01-01 4:22 UTC (permalink / raw) To: esr; +Cc: esr, nickrob, emacs-devel > Date: Mon, 31 Dec 2007 19:50:51 -0500 > From: "Eric S. Raymond" <esr@thyrsus.com> > Cc: esr@snark.thyrsus.com, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > > Nick Roberts <nickrob@snap.net.nz>: > > Stating that Emacs has weak leadership is a ridiculous assertion as it's > > a highly successful project by any standards. > > The "weak leadership" characterization was Eli's, not mine. I didn't say "weak leadership", I said head maintainers that have more time to spend on Emacs development and leadership than what we have now. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 4:22 ` Eli Zaretskii @ 2008-01-01 6:20 ` Eric S. Raymond 0 siblings, 0 replies; 258+ messages in thread From: Eric S. Raymond @ 2008-01-01 6:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, nickrob, emacs-devel Eli Zaretskii <eliz@gnu.org>: > > Date: Mon, 31 Dec 2007 19:50:51 -0500 > > From: "Eric S. Raymond" <esr@thyrsus.com> > > Cc: esr@snark.thyrsus.com, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > > > > Nick Roberts <nickrob@snap.net.nz>: > > > Stating that Emacs has weak leadership is a ridiculous assertion as it's > > > a highly successful project by any standards. > > > > The "weak leadership" characterization was Eli's, not mine. > > I didn't say "weak leadership", I said head maintainers that have more > time to spend on Emacs development and leadership than what we have > now. Fair enough. I didn't intend any aspersion on Richard. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 21:41 ` Eric S. Raymond 2007-12-31 23:00 ` Nick Roberts @ 2007-12-31 23:12 ` Eli Zaretskii 2008-01-01 0:27 ` Dan Nicolaescu 2008-01-01 0:57 ` Eric S. Raymond 2008-01-01 0:10 ` Miles Bader 2 siblings, 2 replies; 258+ messages in thread From: Eli Zaretskii @ 2007-12-31 23:12 UTC (permalink / raw) To: esr; +Cc: esr, emacs-devel > Date: Mon, 31 Dec 2007 16:41:08 -0500 > From: "Eric S. Raymond" <esr@thyrsus.com> > Cc: esr@snark.thyrsus.com, emacs-devel@gnu.org > > I proudly mentioned my work on VC-mode, and got majorly dumped on for > bothering with Emacs at all. The kids out there think we're a > stagnant backwater, an old-boys club of bearded grognards that has > learned nothing and forgotten nothing for the last decade. Curiously enough, I'm having an opposite experience these days: a bunch of extremely able developers who work for years with MS Visual Studio came to respect Emacs, as a viable and powerful alternative to the bloated and dog-slow Studio, even on Windows, to say nothing of GNU/Linux (this is a dual-platform project, where software is developed to run on both systems). All I needed to do is introduce them to some optional features, such as Speedbar, ebrowse, and gdb-ui, and craft a simple .emacs to bind the various Fn keys to compile/run/debug commands they were used to have. After that, I never again heard anyone of them laughing at "stagnant backwater" that is Emacs. Of course, I'm not saying that Emacs is going to win proprietary IDEs any time soon, just that not everybody "dumps" us right away. > In particular, crappy tools and weak leadership hinder attracting new > developers. I can't solve the weak leadership problem, so I'm > focusing on what I know how to do: fix the tools. Sorry, I was taught to identify the 80-20 divide and concentrate on the 80 part before I turn to the other 20. I don't see a point in a revolution that wastes everybody's resources just to produce a 20% or 25% improvement. But that's me. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 23:12 ` Eli Zaretskii @ 2008-01-01 0:27 ` Dan Nicolaescu 2008-01-01 3:00 ` Mike Mattie 2008-01-01 20:44 ` Eli Zaretskii 2008-01-01 0:57 ` Eric S. Raymond 1 sibling, 2 replies; 258+ messages in thread From: Dan Nicolaescu @ 2008-01-01 0:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > > Date: Mon, 31 Dec 2007 16:41:08 -0500 > > From: "Eric S. Raymond" <esr@thyrsus.com> > > Cc: esr@snark.thyrsus.com, emacs-devel@gnu.org > > > > I proudly mentioned my work on VC-mode, and got majorly dumped on for > > bothering with Emacs at all. The kids out there think we're a > > stagnant backwater, an old-boys club of bearded grognards that has > > learned nothing and forgotten nothing for the last decade. > > Curiously enough, I'm having an opposite experience these days: a > bunch of extremely able developers who work for years with MS Visual > Studio came to respect Emacs, as a viable and powerful alternative to > the bloated and dog-slow Studio, even on Windows, to say nothing of > GNU/Linux (this is a dual-platform project, where software is > developed to run on both systems). All I needed to do is introduce > them to some optional features, such as Speedbar, ebrowse, and gdb-ui, > and craft a simple .emacs to bind the various Fn keys to > compile/run/debug commands they were used to have. After that, I > never again heard anyone of them laughing at "stagnant backwater" that > is Emacs. Care to post an example of such .emacs? Maybe it can be used as a skeleton for a package for such users, or maybe we can change some defaults to match such users' expectations. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 0:27 ` Dan Nicolaescu @ 2008-01-01 3:00 ` Mike Mattie 2008-01-01 7:57 ` Drew Adams ` (3 more replies) 2008-01-01 20:44 ` Eli Zaretskii 1 sibling, 4 replies; 258+ messages in thread From: Mike Mattie @ 2008-01-01 3:00 UTC (permalink / raw) To: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 5207 bytes --] On Mon, 31 Dec 2007 16:27:07 -0800 Dan Nicolaescu <dann@ics.uci.edu> wrote: > Eli Zaretskii <eliz@gnu.org> writes: > > > > Date: Mon, 31 Dec 2007 16:41:08 -0500 > > > From: "Eric S. Raymond" <esr@thyrsus.com> > > > Cc: esr@snark.thyrsus.com, emacs-devel@gnu.org > > > > > > I proudly mentioned my work on VC-mode, and got majorly dumped > > > on for bothering with Emacs at all. The kids out there think > > > we're a stagnant backwater, an old-boys club of bearded > > > grognards that has learned nothing and forgotten nothing for > > > the last decade. > > > > Curiously enough, I'm having an opposite experience these days: a > > bunch of extremely able developers who work for years with MS > > Visual Studio came to respect Emacs, as a viable and powerful > > alternative to the bloated and dog-slow Studio, even on Windows, > > to say nothing of GNU/Linux (this is a dual-platform project, > > where software is developed to run on both systems). All I > > needed to do is introduce them to some optional features, such as > > Speedbar, ebrowse, and gdb-ui, and craft a simple .emacs to bind > > the various Fn keys to compile/run/debug commands they were used > > to have. After that, I never again heard anyone of them laughing > > at "stagnant backwater" that is Emacs. > > Care to post an example of such .emacs? > Maybe it can be used as a skeleton for a package for such users, or > maybe we can change some defaults to match such users' expectations. I have tried to do something like this but I have constantly run into what I think is the true issue facing Emacs, the fact that it is forked almost to death. There are three forks of Emacs for Mac OS X, cedet is maintained outside of the mainline, the Ohio Lisp archive died ages ago, slime is third party, and icicles distributes through the emacs wiki. Why does Emacs branch, until the branches become so old that you are forced to admit they are a fork ? It may be that Emacs simply tries to set a higher standard for merging, a standard that the current tools and practices do not support well. Or there may be an artificial barrier. As long as assembling a modern, slick Emacs consists of scavenging various pieces scattered across the net with unreliable hosting, and uncertain maintainer-ship, it's extremely hard to build a cross-platform Emacs. I have found the Emacs community to be one of the most responsive and skilled group of developers in open-source, but trying to straddle all the schisms to support users is really hard. Here is a code example of how I am trying to solve this problem. When I have a part of the emacs setup that is only distributed with some of the emacs forks, or none I split the setup into a separate file. I have a macro that traps errors on load. (defmacro load-guard ( file error ) "Trap errors from loading a file for robustness while initializing." `(condition-case nil (load (concat my-emacs-dir ,file)) (error (progn ;; duplicate the message to both *Messages* as a log ;; and to the *scratch* buffer where it is highly visible. (message "initialization failed %s" ,error) (with-current-buffer "*scratch*" (goto-char (point-max)) (insert (format "; !degraded configuration! %s\n" ,error))) )) )) Inside the file for spelling support I start it with something like this: (defun install-flyspell () "install or update flyspell" (interactive) (dl-elisp "http://www-sop.inria.fr/mimosa/Manuel.Serrano/flyspell/flyspell-1.7n.el" "flyspell")) (require 'flyspell) config.... The idea is that if require fails then it raises an error, and the user has a function to install the functionality. They can then re-execute the configuration once the necessary elisp is installed. Each of the files must have all of the features required as require forms to ensure that it does not configure features that are not installed. This could be made into a much slicker macro that would generate the check,install defuns from a nice syntax. This scheme in practice really doesn't work all that well, because you need reliable hosting for the packages, and you need the last 5 or 10 versions with the version encoded in the URL/path so you can lock a config to a known good version tested against the other components. The provide/require lacks version information. That is another killer. Emacs.app provides flyspell, but what version ? I am not proposing this sort of lightweight package management as a solution, rather as an example of the reality of trying to create an Emacs setup that includes all of the wonderful creativity and innovation that is the hallmark of Emacs. So why do Emacs branches last for years instead of months ? Why is Emacs forked to death ? These are not rhetorical punctuations of a vision, but rather real questions. > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-devel [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 258+ messages in thread
* RE: What a modern collaboration toolkit looks like 2008-01-01 3:00 ` Mike Mattie @ 2008-01-01 7:57 ` Drew Adams 2008-01-02 19:28 ` Agustin Martin ` (2 subsequent siblings) 3 siblings, 0 replies; 258+ messages in thread From: Drew Adams @ 2008-01-01 7:57 UTC (permalink / raw) To: Mike Mattie, emacs-devel > I have constantly run into what I think is the true issue facing > Emacs, the fact that it is forked almost to death. > > There are three forks of Emacs for Mac OS X, cedet is maintained outside > of the mainline, the Ohio Lisp archive died ages ago, slime is > third party, and icicles distributes through the emacs wiki. I really, really (!) do not want to get involved with this thread. But since you opened a tiny parenthesis by mentioning Icicles, Mike, I'll respond to that. [Inserts foot in door.] There are lots of libraries and code snippets that are distributed on Emacs Wiki. And that's a good thing, not a bad thing. gnu-emacs-sources is also a good place to distribute libraries. Nothing wrong with either. I don't interpret your remark negatively, but as a compliment. But I want to be clear that Icicles and many other libraries that are not distributed as part of Emacs do not constitute forks of Emacs. As far as Icicles is concerned, it is compatible with Emacs 20 through 23. IOW, it is more compatible with Emacs than Emacs is. ;-) There are lots of possible reasons why a given library is not integrated with Emacs and distributed as part of it. The Emacs world is not limited to GNU Emacs, and even the GNU Emacs world is not limited to the code distributed with GNU Emacs. The fact that there are multiple degrees of unity and multiple means of distribution is rather a sign of vitality, IMO, not of decline. Speaking only of Icicles, using it as an example, I will say that though there would be some advantages to having Icicles as part of Emacs, there would be some disadvantages also. Since it is separate, I am the only author, and the user base is relatively small, who cares? I am free to take it where I like, which means I can shape it in any weird way I might dream up. IOW, Icicles has the benefit of being a lab, and I have the privilege of playing mad scientist. Don't get me wrong, I try to respond to users, as you know, but it's not the same sort of sober commitment that Emacs development offers. To me, Emacs is a game, not just a tool to get a job done. I don't even use Emacs for anything anymore - just for farting around with Emacs Lisp, an end in itself, a job I never want to get done. The plus side of this state of affairs is that Icicles can serve as a set of UI experiments - a late night snack for thought. The minus side is that if you get addicted to using it you might want to save a copy of today's version because tomorrow's might be too far out there for your taste ;-). Ya never know. And you have only one developer to deal with, which also has its pros and cons. I would say that (1) it is generally good that Emacs developers take the integrity of the Emacs code base seriously, and (2) there is also room for Emacs development outside the innermost tent. When it comes to things I would like to see changed in Emacs, I sometimes find (nameless) Emacs developers too close-minded and tight-assed. I tell myself that they lack imagination. But when it comes to things that I don't want to see changed in Emacs, I can find the same developers too loosey-goosey and wish they'd stop messing it up arbitrarily. Taken together, and given that I am only one consumer of Emacs, those opposite judgments probably indicate that the developers are not too far off track on average. ;-) So consider this my toast to the New Year - here's to Emacs! Nah, not to you guys - Emacs is more than any of us, RMS included. Emacs has a life of its own. Offspring are like that. And I'd be willing to bet that it will have a very long life. My guess is that Emacs will outlive the future daughter of the youngest gadget-&-gamesick, pimply and ircsome recruit that any pied-piper pledge drive might bring under its spell. Nothing wrong with cross-fertilization, new blood, new tools, and new means of discussion, development, and distribution. All of that wake-up-and-smell-the-coffee pep-talk stuff is about us and GNU Emacs as a project, however; it's not so much about Emacs. Emacs dead or declining? Nah. 40 years from now, in another cocktail soiree, someone will still be prancing on about how dull, old-fashioned, and decrepit Emacs is, and everyone there will nod and agree and wonder how and why it still keeps dragging its sorry, tres depassee ass along. Why doesn't someone put the damn thing out of its misery? But Ol' Man Emacs, dat Ol' Man Emacs, he mus' know sumpin', but don' say nothin'; he jes' keeps rollin', he keeps on rollin' along... ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 3:00 ` Mike Mattie 2008-01-01 7:57 ` Drew Adams @ 2008-01-02 19:28 ` Agustin Martin 2008-01-03 9:50 ` Richard Stallman 2008-01-03 9:50 ` Richard Stallman 3 siblings, 0 replies; 258+ messages in thread From: Agustin Martin @ 2008-01-02 19:28 UTC (permalink / raw) To: Mike Mattie; +Cc: emacs-devel On Mon, Dec 31, 2007 at 07:00:34PM -0800, Mike Mattie wrote: > Inside the file for spelling support I start it with something like this: > > (defun install-flyspell () > "install or update flyspell" > (interactive) > (dl-elisp "http://www-sop.inria.fr/mimosa/Manuel.Serrano/flyspell/flyspell-1.7n.el" "flyspell")) > > (require 'flyspell) > > config.... Just a side note here, Manuel is no longer maintaining flyspell.el, although he puts some flyspell.el in his personal page. flyspell.el from emacs cvs is by far more up-to-date, but you may need an actual emacs for some of the features. -- Agustin ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 3:00 ` Mike Mattie 2008-01-01 7:57 ` Drew Adams 2008-01-02 19:28 ` Agustin Martin @ 2008-01-03 9:50 ` Richard Stallman 2008-01-05 3:34 ` Mike Mattie 2008-01-03 9:50 ` Richard Stallman 3 siblings, 1 reply; 258+ messages in thread From: Richard Stallman @ 2008-01-03 9:50 UTC (permalink / raw) To: Mike Mattie; +Cc: emacs-devel I have found the Emacs community to be one of the most responsive and skill= ed=20 group of developers in open-source, Please do not use the term "open source" to describe what Emacs is in. Emacs is part of the GNU Project, which is part of the free software movement. To call us "open source" is like callingt Kucinich a Republican. , but trying to straddle all the schisms = to=20 support users is really hard. We sometimes adopt features to make it easier for code to run in the variants of Emacs. But I don't really understand what you mean by "split the setup" here, When I hav= e a part of the emacs setup that is only distributed with some of the emacs forks, o= r none I split the setup into a separate file. so I don't understand the issue. Inside the file for spelling support I start it with something like this: What is "the file for spelling support"? I am totally lost. Do you mean ispell.el? If not that, then what? ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-03 9:50 ` Richard Stallman @ 2008-01-05 3:34 ` Mike Mattie 2008-01-06 8:09 ` Richard Stallman 0 siblings, 1 reply; 258+ messages in thread From: Mike Mattie @ 2008-01-05 3:34 UTC (permalink / raw) To: rms; +Cc: emacs developers [-- Attachment #1.1: Type: text/plain, Size: 6199 bytes --] On Thu, 03 Jan 2008 04:50:57 -0500 Richard Stallman <rms@gnu.org> wrote: > I have found the Emacs community to be one of the most responsive > and skill= ed=20 > group of developers in open-source, > > Please do not use the term "open source" to describe what Emacs is in. > Emacs is part of the GNU Project, which is part of the free software > movement. To call us "open source" is like callingt Kucinich a > Republican. > > , but trying to straddle all the schisms = > to=20 > support users is really hard. > > We sometimes adopt features to make it easier for code > to run in the variants of Emacs. But I don't really understand > what you mean by "split the setup" here, I think I can articulate this a bit better now. My interest in this thread revolved around the idea of a more advanced Emacs user being able to help a newer user setup a Emacs environment that is appealing with more features than the default configuration. Helping a new user requires some subtly, as simply dumping a large configuration on a new user does not work well. An older user has had alot of time to add the customizations incrementally and adjust to them incrementally. The new user when they receive such a configuration first has to get the configuration running. If the advanced user has downloaded alot of third-party elisp the configuration file will likely generate errors and abort the loading of the configuration file. The new user also has to integrate the new features and behavior into their workflow which takes time, and is alot easier when done in small pieces. So split the setup means break up the user's .emacs file into parts: config/ .emacs style/ -> spell.el ; spell features -> lisp.el ; lisp programming features the .emacs file is carefully coded to make sure that it has a low risk of errors. Note that the style directory is not included in load-path deliberately. I named the directory style as a metaphor from the world of martial arts. In martial arts the harmonious blend of a set of techniques is often called a "fighting style" or some such thing. In this case turning on, adding, and customizing the various spelling features of Emacs to the point where spelling support is pervasive and well integrated constitutes a modular style of using Emacs. each of these large customization files such as spell.el have this basic form: phase 1: define a installer phase 2: check dependencies with require phase 3: perform customization My simple load-guard macro trapped errors during loading and suggests a installation method. The installation method does not necessarily need to be a package manager implemented in elisp. A table that maps features to package names for various package managers is sufficient. The final piece is a nice Emacs interface to the common package managers. With a configuration split up in the way I have described above it is alot easier to help another user use and learn the more advanced capabilities of Emacs. The advanced configuration is split up into parts like a curriculum. They can turn on all of "Guru Bob's" spelling features and integrate them into their workflow without having to learn at the same time all of his lisp tweaks, and other enhancements. A typical scenario would then go something like this: 1. User request's some help getting their Emacs setup with some of Bob's (Guru) features. 2. User receives The Guru's modular configuration and installs it. 3. The user chooses a feature set they are going to integrate into their work-flow, so they move the configuration for the features into the style directory where it will be picked up by the core .emacs file. 4. When they start emacs next it will likely not have necessary libraries, and so It tells them that the configuration is degraded and that they can type "install-foo" to fetch the necessary parts. 5. install foo determines what package manager is in use on the host, and searches the package system for the package names. It displays the search results for the user with a interface that generates the correct package manager commands and feeds them to the package manager via sudo or su if necessary. 6. with the libraries installed they can load the configuration file again. Since it aborted when the dependencies weren't met it didn't leave Emacs in a partially configured state. It doesn't require especially clever code to construct a configuration like this, just a little bit of elisp and a plan for how the configuration is organized. Assuming that Emacs is a good fit for the user they will likely pick it up fairly quickly, and soon write their own configuration. Without the beginning of the learning curve being broken up into steps it is very hard for even a eager new user to comprehend the potential of Emacs, especially when they are trying to quickly match the productivity of their old environment. The end result is a a middle ground for the new user. Instead of a dilemma of either starting from scratch and cherry-picking random elisp code without the elisp skills to integrate the code fragements properly, or choosing a massive jumbo configuration with another foreboding learning curve and no upgrade path, they can now incrementally adopt advanced features and configuration incrementally. A good question at this point is where does this fit into Emacs ? I have seen many "Jumbo configs" for java etc. A best practices guide for creating such configurations, along with some modes for the common package managers out there might be useful. > When I hav= > e a part > of the emacs setup that is only distributed with some of the > emacs forks, o= r none > I split the setup into a separate file. > > so I don't understand the issue. > > Inside the file for spelling support I start it with something > like this: > > What is "the file for spelling support"? I am totally lost. > Do you mean ispell.el? If not that, then what? Hopefully I have explained it a bit better, if not let me know. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 3:34 ` Mike Mattie @ 2008-01-06 8:09 ` Richard Stallman 0 siblings, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-06 8:09 UTC (permalink / raw) To: Mike Mattie; +Cc: emacs-devel So split the setup means break up the user's .emacs file into parts: config/ .emacs style/ -> spell.el ; spell features -> lisp.el ; lisp programming features the .emacs file is carefully coded to make sure that it has a low risk of errors. Note that the style directory is not included in load-path deliberately. We ask people not to start off beginners with a customized Emacs. A new users should learn a standard Emacs, and then customize it if he wants to customize it. But he shouldn't be led into using something nonstandard before he knows the difference. In this case turning on, adding, and customizing the various spelling features of Emacs to the point where spelling support is pervasive and well integrated constitutes a modular style of using Emacs. Do you think that enabling the spelling features of Emacs is complex? If so, maybe we should simplify it. That would be a better solution to this problem, if it exists. each of these large customization files such as spell.el have this basic fo= rm: phase 1: define a installer phase 2: check dependencies with require phase 3: perform customization Why is so much needed just to enable spelling features? 1. User request's some help getting their Emacs setup with some of Bob's (G= uru) features. 2. User receives The Guru's modular configuration and installs it. If "Bob's features" refers to Lisp packages not included in Emacs, then why not install them in the standard directory on the user's machine? There `load-library' will find them without any special effort. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 3:00 ` Mike Mattie ` (2 preceding siblings ...) 2008-01-03 9:50 ` Richard Stallman @ 2008-01-03 9:50 ` Richard Stallman 3 siblings, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-03 9:50 UTC (permalink / raw) To: Mike Mattie; +Cc: emacs-devel I have found the Emacs community to be one of the most responsive and skill= ed=20 group of developers in open-source, Please do not use the term "open source" to describe what Emacs is in. Emacs is part of the GNU Project, which is part of the free software movement. To call us "open source" is like calling Kucinich a Republican. See http://www.gnu.org/philosophy/open-source-misses-the-point.html for more explanation. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 0:27 ` Dan Nicolaescu 2008-01-01 3:00 ` Mike Mattie @ 2008-01-01 20:44 ` Eli Zaretskii 2008-01-02 4:17 ` Dan Nicolaescu 1 sibling, 1 reply; 258+ messages in thread From: Eli Zaretskii @ 2008-01-01 20:44 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: emacs-devel > From: Dan Nicolaescu <dann@ics.uci.edu> > Cc: emacs-devel@gnu.org > Date: Mon, 31 Dec 2007 16:27:07 -0800 > > > All I needed to do is introduce > > them to some optional features, such as Speedbar, ebrowse, and gdb-ui, > > and craft a simple .emacs to bind the various Fn keys to > > compile/run/debug commands they were used to have. After that, I > > never again heard anyone of them laughing at "stagnant backwater" that > > is Emacs. > > Care to post an example of such .emacs? > Maybe it can be used as a skeleton for a package for such users, or > maybe we can change some defaults to match such users' expectations. There's nothing too fancy about it; most of it goes like this: (defun ez-clcheckout () "Checkout from ClearCase the file visited by current buffer." (interactive) (shell-command (format "cleartool co %s" buffer-file-name)) (revert-buffer nil t)) (global-set-key (kbd "<f9>") 'ez-clcheckout) (defun ez-clcheckin () "Checkin to ClearCase the file visited by current buffer." (interactive) (shell-command (format "cleartool ci %s" buffer-file-name)) (revert-buffer nil t)) (global-set-key (kbd "<C-f9>") 'ez-clcheckin) (defun ez-maketarg () "Build the project in current buffer's directory." (interactive) (save-buffer) (if (eq system-type 'windows-nt) (compile compile-command) (compile "gmake -k DEBUG"))) (global-set-key (kbd "<f7>") 'ez-maketarg) (add-hook 'c-mode-common-hook (lambda () (unless (or (file-exists-p "makefile") (file-exists-p "Makefile")) (let* ((dsp-dir (file-name-directory buffer-file-name)) (dsp-file (downcase (file-name-nondirectory (directory-file-name dsp-dir))))) (set (make-local-variable 'compile-command) (concat "devenv.com " (convert-standard-filename dsp-dir) dsp-file ".vcproj debug /rebuild")))))) (global-set-key (kbd "<f4>") 'next-error) ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 20:44 ` Eli Zaretskii @ 2008-01-02 4:17 ` Dan Nicolaescu 2008-01-05 10:48 ` Eli Zaretskii 0 siblings, 1 reply; 258+ messages in thread From: Dan Nicolaescu @ 2008-01-02 4:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > > From: Dan Nicolaescu <dann@ics.uci.edu> > > Cc: emacs-devel@gnu.org > > Date: Mon, 31 Dec 2007 16:27:07 -0800 > > > > > All I needed to do is introduce > > > them to some optional features, such as Speedbar, ebrowse, and gdb-ui, > > > and craft a simple .emacs to bind the various Fn keys to > > > compile/run/debug commands they were used to have. After that, I > > > never again heard anyone of them laughing at "stagnant backwater" that > > > is Emacs. > > > > Care to post an example of such .emacs? > > Maybe it can be used as a skeleton for a package for such users, or > > maybe we can change some defaults to match such users' expectations. > > There's nothing too fancy about it; most of it goes like this: Thanks. > (defun ez-clcheckout () > "Checkout from ClearCase the file visited by current buffer." > (interactive) > (shell-command (format "cleartool co %s" buffer-file-name)) > (revert-buffer nil t)) > (global-set-key (kbd "<f9>") 'ez-clcheckout) > (defun ez-clcheckin () > "Checkin to ClearCase the file visited by current buffer." > (interactive) > (shell-command > (format "cleartool ci %s" buffer-file-name)) > (revert-buffer nil t)) > (global-set-key (kbd "<C-f9>") 'ez-clcheckin) Maybe this should use vc-clearcase (if such a thing exists). Are the f9 and C-f9 the usual keys for this type of functionality in one some platforms? Would be useful for us to add some default extra bindings to the functions keys for the VC functions? > (defun ez-maketarg () > "Build the project in current buffer's directory." > (interactive) > (save-buffer) > (if (eq system-type 'windows-nt) > (compile compile-command) > (compile "gmake -k DEBUG"))) > > (global-set-key (kbd "<f7>") 'ez-maketarg) > (add-hook 'c-mode-common-hook > (lambda () > (unless (or (file-exists-p "makefile") > (file-exists-p "Makefile")) > (let* ((dsp-dir (file-name-directory buffer-file-name)) > (dsp-file (downcase (file-name-nondirectory > (directory-file-name dsp-dir))))) > (set (make-local-variable 'compile-command) > (concat "devenv.com " > (convert-standard-filename dsp-dir) > dsp-file > ".vcproj debug /rebuild")))))) I always wished we had a nice one key binding to a "smart" version of M-x compile... > (global-set-key (kbd "<f4>") 'next-error) We already use f4, so this can't be bound by default :-( ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 4:17 ` Dan Nicolaescu @ 2008-01-05 10:48 ` Eli Zaretskii 0 siblings, 0 replies; 258+ messages in thread From: Eli Zaretskii @ 2008-01-05 10:48 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: emacs-devel > From: Dan Nicolaescu <dann@ics.uci.edu> > Cc: emacs-devel@gnu.org > Date: Tue, 01 Jan 2008 20:17:36 -0800 > > > (defun ez-clcheckout () > > "Checkout from ClearCase the file visited by current buffer." > > (interactive) > > (shell-command (format "cleartool co %s" buffer-file-name)) > > (revert-buffer nil t)) > > (global-set-key (kbd "<f9>") 'ez-clcheckout) > > (defun ez-clcheckin () > > "Checkin to ClearCase the file visited by current buffer." > > (interactive) > > (shell-command > > (format "cleartool ci %s" buffer-file-name)) > > (revert-buffer nil t)) > > (global-set-key (kbd "<C-f9>") 'ez-clcheckin) > > Maybe this should use vc-clearcase (if such a thing exists). It exists, but the users for whom I made these customizations weren't used to having any interface to ClearCase in the IDE besides checkout/checkin commands. So I didn't bother installing vc-clearcase, because doing so would need to make global changes on our several dozen lab computers. > Are the f9 and C-f9 the usual keys for this type of functionality in > one some platforms? AFAIU, they are in Visual Studio. > Would be useful for us to add some default extra bindings to the > functions keys for the VC functions? Probably. > > (global-set-key (kbd "<f4>") 'next-error) > > We already use f4, so this can't be bound by default :-( Yeah, and I'd be damned if I understand why it's important. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 23:12 ` Eli Zaretskii 2008-01-01 0:27 ` Dan Nicolaescu @ 2008-01-01 0:57 ` Eric S. Raymond 2008-01-01 4:21 ` Eli Zaretskii 1 sibling, 1 reply; 258+ messages in thread From: Eric S. Raymond @ 2008-01-01 0:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, emacs-devel Eli Zaretskii <eliz@gnu.org>: > > I proudly mentioned my work on VC-mode, and got majorly dumped on for > > bothering with Emacs at all. > > Curiously enough, I'm having an opposite experience these days: I completely believe you. I think our accounts unify nicely if you reflect that the people giving me crap were mainly Eclipse fans -- ex-Emacs users who think they've found something better. On the other hand, anybody who's been stuck using Microsoft tools... well, of *course* Emacs is better; an Acheulian flint hand-axe would probably strike those poor bastards as an improvement. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 0:57 ` Eric S. Raymond @ 2008-01-01 4:21 ` Eli Zaretskii 0 siblings, 0 replies; 258+ messages in thread From: Eli Zaretskii @ 2008-01-01 4:21 UTC (permalink / raw) To: esr; +Cc: esr, emacs-devel > Date: Mon, 31 Dec 2007 19:57:49 -0500 > From: "Eric S. Raymond" <esr@thyrsus.com> > Cc: esr@snark.thyrsus.com, emacs-devel@gnu.org > > On the other hand, anybody who's been stuck using Microsoft tools... These tools still have a few features that Emacs could benefit from, such as a better class browser, visual code folding, function and variable hints in tooltips, etc. Ebrowse did not see any significant development since its introduction in v21.1. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 21:41 ` Eric S. Raymond 2007-12-31 23:00 ` Nick Roberts 2007-12-31 23:12 ` Eli Zaretskii @ 2008-01-01 0:10 ` Miles Bader 2008-01-01 1:06 ` Eric S. Raymond 2008-01-01 19:43 ` Tom Tromey 2 siblings, 2 replies; 258+ messages in thread From: Miles Bader @ 2008-01-01 0:10 UTC (permalink / raw) To: esr; +Cc: esr, Eli Zaretskii, emacs-devel "Eric S. Raymond" <esr@thyrsus.com> writes: > Boy howdy, did I get a faceful of it last night at my friends the > Matuszeks' post-Yule party. They're AI researchers and their parties > attract a rather dizzying assortment of alpha geeks, ... > I proudly mentioned my work on VC-mode, and got majorly dumped on for > bothering with Emacs at all. These people apparently treat software as some kind of fashion contest. Do you expect us to put any stock in what they say? -MIles -- The secret to creativity is knowing how to hide your sources. --Albert Einstein ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 0:10 ` Miles Bader @ 2008-01-01 1:06 ` Eric S. Raymond 2008-01-01 1:41 ` Miles Bader 2008-01-01 19:43 ` Tom Tromey 1 sibling, 1 reply; 258+ messages in thread From: Eric S. Raymond @ 2008-01-01 1:06 UTC (permalink / raw) To: Miles Bader; +Cc: esr, Eli Zaretskii, emacs-devel Miles Bader <miles@gnu.org>: > These people apparently treat software as some kind of fashion contest. > Do you expect us to put any stock in what they say? Well...at least two of them, to my certain personal knowledge, have been expert Emacs users in the past. (I'm thinking of David and Cyndy Matuszek, in case anyone here has ever met them.) They're not fashionistas. They have a belief, which is not badly founded given the evidence available to them, that the Emacs project is old, tired, badly run, and effectively moribund. I can't say that I blame them much for this. We have a lot of work to do to re-establish the level of credibility we enjoyed at the time I was last directly involved in the early 1990s. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 1:06 ` Eric S. Raymond @ 2008-01-01 1:41 ` Miles Bader 2008-01-01 2:16 ` Eric S. Raymond 0 siblings, 1 reply; 258+ messages in thread From: Miles Bader @ 2008-01-01 1:41 UTC (permalink / raw) To: esr; +Cc: esr, Eli Zaretskii, emacs-devel "Eric S. Raymond" <esr@thyrsus.com> writes: > They're not fashionistas. They have a belief, which is not badly founded > given the evidence available to them, that the Emacs project is old, > tired, badly run, and effectively moribund. Are they judging the software, or the "project"? In my activitiy as a "branch merger", as well as reading the mailing list, I see the activity of the Emacs project in a fair amount of detail. It's quite clear to me that while the Emacs project is obviously old (hard to change that :-), it's neither "tired" nor "moribund"; indeed, sometimes I rather wish people would be a bit _less_ enthusiastic about making changes.... :-/ [Note that I'm all for moving to more modern tools. Subversion is probably not a great choice though -- if we're going to change, we should change to one of the distributed systems like git.] -Miles -- The key to happiness is having dreams. [from a fortune cookie] ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 1:41 ` Miles Bader @ 2008-01-01 2:16 ` Eric S. Raymond 0 siblings, 0 replies; 258+ messages in thread From: Eric S. Raymond @ 2008-01-01 2:16 UTC (permalink / raw) To: Miles Bader; +Cc: esr, Eli Zaretskii, emacs-devel Miles Bader <miles@gnu.org>: > "Eric S. Raymond" <esr@thyrsus.com> writes: > > They're not fashionistas. They have a belief, which is not badly founded > > given the evidence available to them, that the Emacs project is old, > > tired, badly run, and effectively moribund. > > Are they judging the software, or the "project"? Fair question. I caught a little of both. I'm not sure they're clearly distinguished in the critics' thinking. David Matuszek (star CS professor at UPenn) has been griping at me for years about things like features he relied upon disappearing during version upgrades. He's made it very clear that he thinks this sort of thing is a symptom of inattention to what users are actually doing with the software by developers too obsessed with the next cool hack. I think that counts as both software and project croticism. Cyndy (AI researcher, Dave's daughter, formerly with Doug Lenat's Cyc project and now doing a six-year gig in Seattle) didn't particularly slam the software, but was entertainingly rude about CVS. One of her milder remarks was to the effect that "Somebody needs to remind RMS what year it is." There wasn't much I could say about this project criticism given that I pretty completely agree with it. Matt, whose last name I didn't catch but who I think is a software designer at Google, came the closest to having a "fashionista" position; he thinks Eclipse's UI makes Emacs's look paleolithic. There was someone else in the discussion who's a doctoral candidate at CMU doing research in language design -- I don't remember what her gripe was but she sure wasn't giving Emacs any love. It was rather unnerving. > [Note that I'm all for moving to more modern tools. Subversion is > probably not a great choice though -- if we're going to change, we > should change to one of the distributed systems like git.] Agreed, one of the 3Gs would be better. I'm doing a technical survey paper on them now; I'll be *extremely* well equipped to choose one well-fitted for the Emacs project's needs when that's done. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 0:10 ` Miles Bader 2008-01-01 1:06 ` Eric S. Raymond @ 2008-01-01 19:43 ` Tom Tromey 2008-01-01 21:11 ` Nick Roberts ` (2 more replies) 1 sibling, 3 replies; 258+ messages in thread From: Tom Tromey @ 2008-01-01 19:43 UTC (permalink / raw) To: Miles Bader; +Cc: esr, esr, Eli Zaretskii, emacs-devel >>>>> "Miles" == Miles Bader <miles@gnu.org> writes: Miles> These people apparently treat software as some kind of fashion Miles> contest. Do you expect us to put any stock in what they say? I tell all my friends that I work in a fashion industry :-). How else to explain the long parade of fads and silver bullets, or at least silver-handled six-shooters? But seriously... A couple years ago, after using and loving Emacs for 15 years, I moved all my Java development into Eclipse. I did this despite the facts that Eclipse's editor is amazingly bad and its UI is clunky and impossible to customize. The reason I did this is that Eclipse provides a number of compelling features which Emacs does not. At least, it does for Java -- for other programming languages it is not nearly as useful, IME. * An integrated Java compiler that knows about your whole project. This has a number of nice implications: * No more waiting. It compiles while you type. When you save a file you are ready to run your tests immediately. * Class browsing, call hierarchy information ("find all callers of this method"), intelligent completion, documentation and API help while you type. * Refactoring. E.g., a simple one is "rename this class". If you rename into a different package it will update all users, all import statements, etc. (There are lots of nice refactorings.) * Quick fix. Certain common problems (warnings and whatnot) can come with a fix, you click and Eclipse fixes your code. * Will write the Javadoc "skeleton" for you, so you can just fill in the details. * A problem view. I loved this. Instead of compiling and then stepping through errors and warnings, the view shows everything, is always up-to-date, and is filterable. * Eclipse knows about projects, and you can easily share settings with other developers. (This is what inspired my as-yet-unfinished "project.el" hacks.) This means that getting a new developer up-and-running is extremely easy. Combined with the integrated compiler and build setup, usually a developer can check out a project and immediately have it be built and be ready to work. You can check in launchers so that common test or debug invocations are automatically available after checkout. Many features are trivial to restrict to the current project -- the problem view, searches, browsing, file-name completion. In Emacs most things are global by default -- you can run a single gdb, find-tag uses a global tags buffer, etc. * The version control UI is much friendlier than VC. At least, that is true as of a couple weeks ago. Newer versions have bugzilla integration, and task-based ways to filter what you work on and see ("mylyn" -- I still haven't played with this). The above is necessarily a brief list. I can go into more detail if you really want. Basically, for Java, Eclipse changed the way I work. It pained me to make this move. I love Emacs. But, Emacs doesn't get the same level of investment, and at the time appeared from the outside to be dead (no release in years). None of these features is impossible to implement in Emacs. In fact many could probably be done by reusing Eclipse's Java compiler. Another interesting IDE to look at is NetBeans. I've used it a lot less than I used Eclipse, and it seemed to have fewer killer features. But I went to JavaOne last year and saw something really interesting -- every new technology introduced during a keynote came with a corresponding NetBeans plugin. And, you could get started using that technology *immediately* by going to some online NetBeans repository (accessible directly in the IDE) and downloading the plugin. This is, more or less, where ELPA came from. The idea is simple -- your IDE won't ever contain absolutely everything, so make it trivial to fetch and install helpful packages. (Eclipse also has a plugin downloader, though it is pretty bad.) Anyway, the bar for a programming editor is much higher now than when I started using Emacs. Nowadays intelligent completion, API help, browsing, and refactoring are the baseline. Emacs does some of these in some modes -- elisp is the best example; lisp-complete-symbol and eldoc are quite nice -- but for most modes this stuff is either missing, or the defaults are wrong. I hope you don't mind that I don't enumerate Emacs' many advantages. There are tons of them. Emacs is very, very strong at the mechanics of editing, and it is very simple to extend (lisp may be weird or whatever, but even a trivial Eclipse plugin is really hard). However, while Emacs rocks at these things, the IDEs have been working hard to intelligently analyze source and apply this understanding in useful ways. HTH, Tom ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 19:43 ` Tom Tromey @ 2008-01-01 21:11 ` Nick Roberts 2008-01-02 0:25 ` Miles Bader 2008-01-02 9:53 ` What a modern collaboration toolkit looks like Richard Stallman 2 siblings, 0 replies; 258+ messages in thread From: Nick Roberts @ 2008-01-01 21:11 UTC (permalink / raw) To: Tom Tromey; +Cc: esr, esr, Eli Zaretskii, emacs-devel, Miles Bader > A couple years ago, after using and loving Emacs for 15 years, I moved > all my Java development into Eclipse. I did this despite the facts > that Eclipse's editor is amazingly bad and its UI is clunky and > impossible to customize. > > The reason I did this is that Eclipse provides a number of compelling > features which Emacs does not. At least, it does for Java -- for > other programming languages it is not nearly as useful, IME. > > * An integrated Java compiler that knows about your whole project. > This has a number of nice implications: > > * No more waiting. It compiles while you type. When you save a > file you are ready to run your tests immediately. > * Class browsing, call hierarchy information ("find all callers of > this method"), intelligent completion, documentation and API help > while you type. [snip - long list] Yes, I agree. While Emacs has certainly moved forward over the last few years, relatively it's fallen behind and I suspect many users are moving to other applications like Eclipse. It's a vicious circle: if we are ever to catch up we need more developers and attract them we need more users. That's why I think it's counterproductive to hold back releases for bugs like: ** eric@openbsd.org, 24 Nov: c-mode syntactic analysis regression in emacs-22.1 which might irritate some people but will hardly drive people away from using Emacs in large numbers. A bug tracker could record such bugs and track its status. In my experience, such bugs do get fixed, albeit several releases later. However, if the issue is ideological, i.e., that code is not released with any known bugs is more important than having a user base then there is no argument, of course. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 19:43 ` Tom Tromey 2008-01-01 21:11 ` Nick Roberts @ 2008-01-02 0:25 ` Miles Bader 2008-01-02 1:12 ` Tom Tromey 2008-01-02 9:53 ` What a modern collaboration toolkit looks like Richard Stallman 2 siblings, 1 reply; 258+ messages in thread From: Miles Bader @ 2008-01-02 0:25 UTC (permalink / raw) To: Tom Tromey; +Cc: esr, esr, Eli Zaretskii, emacs-devel Tom Tromey <tromey@redhat.com> writes: > Anyway, the bar for a programming editor is much higher now than when > I started using Emacs. Nowadays intelligent completion, API help, > browsing, and refactoring are the baseline. Emacs does some of these > in some modes -- elisp is the best example; lisp-complete-symbol and > eldoc are quite nice -- but for most modes this stuff is either > missing, or the defaults are wrong. I've actually used Eclipse a lot for Java programming, and it has many nice features (many of which you list). However, it's definitely a mixed bag -- the UI is _so_ baroque and often confusing, and in general so "rigid" (not to mention slowwwwww) that often I found myself wishing for Emacs again. A mixed bag. My wish is that Emacs gets "Emacsy" versions of Eclipse's best features, not that Emacs becomes anything like Eclipse (which has a truly awful user interface...). -Miles -- "Whatever you do will be insignificant, but it is very important that you do it." Mahatma Gandhi ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 0:25 ` Miles Bader @ 2008-01-02 1:12 ` Tom Tromey 2008-01-02 17:19 ` On-the-fly compiling (was Re: What a modern collaboration toolkit looks like) Mark A. Hershberger 0 siblings, 1 reply; 258+ messages in thread From: Tom Tromey @ 2008-01-02 1:12 UTC (permalink / raw) To: Miles Bader; +Cc: esr, esr, Eli Zaretskii, emacs-devel >>>>> "Miles" == Miles Bader <miles@gnu.org> writes: Miles> I've actually used Eclipse a lot for Java programming, and it has many Miles> nice features (many of which you list). However, it's definitely a Miles> mixed bag -- the UI is _so_ baroque and often confusing, and in general Miles> so "rigid" (not to mention slowwwwww) that often I found myself wishing Miles> for Emacs again. A mixed bag. Yeah. For me the tradeoffs were compelling enough to switch -- it made me notably more efficient. But it is true you need a much more powerful machine to run Eclipse. Remember the good old days when people made jokes about Emacs' size? Eclipse uses much more memory. And, if you're used to Emacs' high level of integration and ease of hackability, it takes some getting used to. I think if you are come from a more GUI-ish world, Eclipse is only mildly sucky -- from my GUI-using friends I hear some complaints but mostly around the edges. Miles> My wish is that Emacs gets "Emacsy" versions of Eclipse's best features, Miles> not that Emacs becomes anything like Eclipse (which has a truly awful Miles> user interface...). I'm in complete agreement. And much of it, like java compiler stuff, should not be done in Emacs itself, IMO. Tom ^ permalink raw reply [flat|nested] 258+ messages in thread
* On-the-fly compiling (was Re: What a modern collaboration toolkit looks like) 2008-01-02 1:12 ` Tom Tromey @ 2008-01-02 17:19 ` Mark A. Hershberger 2008-01-02 20:57 ` On-the-fly compiling Stefan Monnier 2008-01-02 23:09 ` Tom Tromey 0 siblings, 2 replies; 258+ messages in thread From: Mark A. Hershberger @ 2008-01-02 17:19 UTC (permalink / raw) To: emacs-devel Tom Tromey <tromey@redhat.com> writes: > Miles> My wish is that Emacs gets "Emacsy" versions of Eclipse's best > Miles> features, not that Emacs becomes anything like Eclipse (which > Miles> has a truly awful user interface...). > > I'm in complete agreement. And much of it, like java compiler stuff, > should not be done in Emacs itself, IMO. Check out flymake which has support for jikes. I am not a Java hacker, but I did set up flymake with Jikes when I was looking at some Java projects. I'd be happy to see if I can dig up that setup again, if you're interested. -- http://hexmode.com/ GPG Fingerprint: 7E15 362D A32C DFAB E4D2 B37A 735E F10A 2DFC BFF5 My happiness grows in direct proportion to my acceptance, and in inverse proportion to my expectations. -- Michael J. Fox ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: On-the-fly compiling 2008-01-02 17:19 ` On-the-fly compiling (was Re: What a modern collaboration toolkit looks like) Mark A. Hershberger @ 2008-01-02 20:57 ` Stefan Monnier 2008-01-02 22:33 ` Lennart Borgman (gmail) 2008-01-02 23:09 ` Tom Tromey 1 sibling, 1 reply; 258+ messages in thread From: Stefan Monnier @ 2008-01-02 20:57 UTC (permalink / raw) To: Mark A. Hershberger; +Cc: emacs-devel > Check out flymake which has support for jikes. I am not a Java hacker, > but I did set up flymake with Jikes when I was looking at some Java > projects. I'd be happy to see if I can dig up that setup again, if > you're interested. I'd be interested to see it and maybe add something like it to flymake.el's documentation. Stefan ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: On-the-fly compiling 2008-01-02 20:57 ` On-the-fly compiling Stefan Monnier @ 2008-01-02 22:33 ` Lennart Borgman (gmail) 0 siblings, 0 replies; 258+ messages in thread From: Lennart Borgman (gmail) @ 2008-01-02 22:33 UTC (permalink / raw) To: Stefan Monnier; +Cc: Mark A. Hershberger, emacs-devel Stefan Monnier wrote: >> Check out flymake which has support for jikes. I am not a Java hacker, >> but I did set up flymake with Jikes when I was looking at some Java >> projects. I'd be happy to see if I can dig up that setup again, if >> you're interested. > > I'd be interested to see it and maybe add something like it to > flymake.el's documentation. Is Jikes maintained? What about this: http://sourceforge.net/project/showfiles.php?group_id=128803 ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: On-the-fly compiling 2008-01-02 17:19 ` On-the-fly compiling (was Re: What a modern collaboration toolkit looks like) Mark A. Hershberger 2008-01-02 20:57 ` On-the-fly compiling Stefan Monnier @ 2008-01-02 23:09 ` Tom Tromey 1 sibling, 0 replies; 258+ messages in thread From: Tom Tromey @ 2008-01-02 23:09 UTC (permalink / raw) To: Mark A. Hershberger; +Cc: emacs-devel >>>>> "Mark" == Mark A Hershberger <mah@everybody.org> writes: Mark> Check out flymake which has support for jikes. I am not a Java hacker, Mark> but I did set up flymake with Jikes when I was looking at some Java Mark> projects. I'd be happy to see if I can dig up that setup again, if Mark> you're interested. Yeah, I haven't done all my "due diligence" -- I haven't tried flymake and I haven't tried JDEE. Auto-building is just one feature among many, though. Even JDEE, AFAICT, only provides a subset of what Eclipse does. Note that jikes is quite far behind the times, Java-wise. I don't know anybody who uses it any more, because it does not support Java 5. Retrofitting this is a major task and, I think, pointless -- there are already 2 free, compliant Java compilers. I think we dropped jikes from Fedora due to obsolescence. Tom ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 19:43 ` Tom Tromey 2008-01-01 21:11 ` Nick Roberts 2008-01-02 0:25 ` Miles Bader @ 2008-01-02 9:53 ` Richard Stallman 2 siblings, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-02 9:53 UTC (permalink / raw) To: Tom Tromey; +Cc: esr, esr, eliz, emacs-devel, miles None of these features is impossible to implement in Emacs. In fact many could probably be done by reusing Eclipse's Java compiler. I would be glad to see any and all of these features added to Emacs. Eclipse is free, so we should be able to use the Eclipse Java compiler. However, I would rather do it in ways that work with GCJ and with other languages too. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 20:57 ` Eli Zaretskii 2007-12-31 21:41 ` Eric S. Raymond @ 2008-01-01 11:28 ` Tassilo Horn 2008-01-01 20:36 ` Eli Zaretskii 2008-01-03 9:50 ` Richard Stallman 1 sibling, 2 replies; 258+ messages in thread From: Tassilo Horn @ 2008-01-01 11:28 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: Hi Eli, > And if you are hinting that using CVS is the reason, then I must say > that in the 15 years I've been involved in Emacs development (using > RCS at first, btw), I don't think I've ever heard some potential > contributor say that she refuses to come on board because of the VCS > we use. Speaking as one of the youngsters in the team, I'd say that it matters quite a bit. There are a lot of emacs lisp projects where younger devs are involved (e.g. EMMS), but getting something into emacs is quite hard. A distributed VCS would help here definitely. The current way with posting patches on emacs-devel, getting review, rewriting the patches, yet more review and eventually being included (but still with no write access) can make the work much harder. Of course I do think that the review is very good thing and that giving write access to a person is a decision that has to be weighted accurately, but a tool like git would free contributors from needing that. I could say, hey, I've developed this new foo-mode, please look at my git repository at http://www.tsdh.de/repos/git/foo, get the review, change it till everybody is satisfied and eventually one of the core devs could pull the changes. There would be no need to have write access at all. I can alway commit to my repository (even when I'm offline, a fact that should be a big plus for Richard) and synching happens whenever something important has be done and some core dev reviewed it. There's a nice video at youtube where Linus Torvalds talks about git where he discribes the benefits of distributed VCSs (in a very entertaining way). > My analysis is different: I think we are limited by a small number of > core developers, and by the lack of head maintainer(s) who could > devote much more time than any of us can evidently provide to coding > and leading the rest of the developers. IMO this would change with a VCS like git, too. On problem with the current situation is that possible contributors might fear that their changes break something or won't be liked by the core devs. So they don't even try it at all. With a distributed VCS it's like everybody has his own branch where he can do what he likes, so I expect people to hack on parts they wouldn't try normally. And since then there will be finished patches which actually are easily appliable and testable, the maintainer's job would be to try the different branches and incorporate the good stuff into the main line. So to sum up: There are quite a few young devs that write good elisp code, but currently they concentrate on extensions, because the core stuff seems somewhat locked behind bureaucratical walls. A distributed version control system would definitely help to break them down. Bye, Tassilo ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 11:28 ` Tassilo Horn @ 2008-01-01 20:36 ` Eli Zaretskii 2008-01-02 0:29 ` Miles Bader ` (2 more replies) 2008-01-03 9:50 ` Richard Stallman 1 sibling, 3 replies; 258+ messages in thread From: Eli Zaretskii @ 2008-01-01 20:36 UTC (permalink / raw) To: Tassilo Horn; +Cc: emacs-devel > From: Tassilo Horn <tassilo@member.fsf.org> > Date: Tue, 01 Jan 2008 12:28:43 +0100 > > The current way with posting patches on emacs-devel, getting review, > rewriting the patches, yet more review and eventually being included > (but still with no write access) can make the work much harder. > [...] > I could say, hey, I've developed this new foo-mode, please look at my > git repository at http://www.tsdh.de/repos/git/foo, get the review, > change it till everybody is satisfied and eventually one of the core > devs could pull the changes. Please explain how the former is harder than the latter. You still need to wait for review and approval. OTOH, having a patch pushed into my INBOX and staring in my face runs better chances that I will review it than if I need to be on-line and type some commands first just to see it. > There's a nice video at youtube where Linus Torvalds talks about git > where he discribes the benefits of distributed VCSs (in a very > entertaining way). Linus and others invented git because Linux kernel development is radically different from Emacs development. To start using git, we need first get to the point the Linux kernel developers are at: lots of developers independently developing all kinds of extensions. _And_ we need a head maintainer who works on nothing else but integration of features she likes into the product that is eventually released. Please also don't forget that, unlike a Linux kernel, Emacs must have good user-level documentation. So decentralized development needs also solve the problem of producing high quality manuals. > IMO this would change with a VCS like git, too. On problem with the > current situation is that possible contributors might fear that their > changes break something or won't be liked by the core devs. So they > don't even try it at all. I don't see why. Someone who wants just to try things can do that in their sandbox; no one will ever know they did it unless they tell or post the patches. How is this different from using git? > So to sum up: There are quite a few young devs that write good elisp > code Do you have numbers? or is "few" == 1 here? ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 20:36 ` Eli Zaretskii @ 2008-01-02 0:29 ` Miles Bader 2008-01-02 4:14 ` Eli Zaretskii 2008-01-02 8:20 ` Tassilo Horn 2008-01-02 8:41 ` tomas 2 siblings, 1 reply; 258+ messages in thread From: Miles Bader @ 2008-01-02 0:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Tassilo Horn, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > To start using git, we need first get to the point the Linux kernel > developers are at: lots of developers independently developing all > kinds of extensions. _And_ we need a head maintainer who works on > nothing else but integration of features she likes into the product > that is eventually released. No we don't (how on earth did you reach that conclusion ?!). Git, like most modern source control systems, is pretty much a _superset_ of CVS, and can happily be used with a CVS-like "central server" (where it still handily beats the pants of CVS in almost every respect). -Miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 0:29 ` Miles Bader @ 2008-01-02 4:14 ` Eli Zaretskii 2008-01-02 4:33 ` Miles Bader 0 siblings, 1 reply; 258+ messages in thread From: Eli Zaretskii @ 2008-01-02 4:14 UTC (permalink / raw) To: Miles Bader; +Cc: tassilo, emacs-devel > From: Miles Bader <miles@gnu.org> > Date: Wed, 02 Jan 2008 09:29:47 +0900 > Cc: Tassilo Horn <tassilo@member.fsf.org>, emacs-devel@gnu.org > > Eli Zaretskii <eliz@gnu.org> writes: > > To start using git, we need first get to the point the Linux kernel > > developers are at: lots of developers independently developing all > > kinds of extensions. _And_ we need a head maintainer who works on > > nothing else but integration of features she likes into the product > > that is eventually released. > > No we don't (how on earth did you reach that conclusion ?!). AFAIK, this is how Linux kernel development works, and that is the single most important basis for the git philosophy. > Git, like most modern source control systems, is pretty much a > _superset_ of CVS, and can happily be used with a CVS-like "central > server" (where it still handily beats the pants of CVS in almost every > respect). IMO, it hardly makes sense to switch, then, and it's not what Tassilo had in mind and put in writing, AFAIU. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 4:14 ` Eli Zaretskii @ 2008-01-02 4:33 ` Miles Bader 2008-01-02 8:24 ` Werner LEMBERG 0 siblings, 1 reply; 258+ messages in thread From: Miles Bader @ 2008-01-02 4:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: tassilo, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> > To start using git, we need first get to the point the Linux kernel >> > developers are at: lots of developers independently developing all >> > kinds of extensions. _And_ we need a head maintainer who works on >> > nothing else but integration of features she likes into the product >> > that is eventually released. >> >> No we don't (how on earth did you reach that conclusion ?!). > > AFAIK, this is how Linux kernel development works, and that is the > single most important basis for the git philosophy. There's a common kernel development style, and git is good at it -- but git has been influenced by _many_ people, and as a result, supports many different working styles quite well (and even kernel development is not so homogeneous -- various sub-projects use a more centralized development style, and yet can inter-operate seemlessly with the main kernel). >> Git, like most modern source control systems, is pretty much a >> _superset_ of CVS, and can happily be used with a CVS-like "central >> server" (where it still handily beats the pants of CVS in almost every >> respect). > > IMO, it hardly makes sense to switch, then, and it's not what Tassilo > had in mind and put in writing, AFAIU. Again: it still handily beats the pants of CVS in almost every respect [when used in "centralized" fashion]. _And_ it gives much more flexibility to developers. For instance, I may normally push changes to the central repository many times a day, but if I go on a vacation, I can bring my laptop and _continue_ commiting changes "locally", and then push them all to the central repository when I get back (preserving all commit boundaries of course). Git allows many development styles to interact seamlessly. I think that's a good thing. -Miles -- o The existentialist, not having a pillow, goes everywhere with the book by Sullivan, _I am going to spit on your graves_. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 4:33 ` Miles Bader @ 2008-01-02 8:24 ` Werner LEMBERG 0 siblings, 0 replies; 258+ messages in thread From: Werner LEMBERG @ 2008-01-02 8:24 UTC (permalink / raw) To: miles; +Cc: eliz, tassilo, emacs-devel > For instance, I may normally push changes to the central repository > many times a day, but if I go on a vacation, I can bring my laptop > and _continue_ commiting changes "locally", and then push them all > to the central repository when I get back (preserving all commit > boundaries of course). Yeah, this is vital for me since I'm travelling a lot with train. It should fit Richard's development style much, much better than CVS! Werner ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 20:36 ` Eli Zaretskii 2008-01-02 0:29 ` Miles Bader @ 2008-01-02 8:20 ` Tassilo Horn 2008-01-03 9:50 ` Richard Stallman 2008-01-02 8:41 ` tomas 2 siblings, 1 reply; 258+ messages in thread From: Tassilo Horn @ 2008-01-02 8:20 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: Hi Eli, >> The current way with posting patches on emacs-devel, getting review, >> rewriting the patches, yet more review and eventually being included >> (but still with no write access) can make the work much harder. >> [...] >> I could say, hey, I've developed this new foo-mode, please look at my >> git repository at http://www.tsdh.de/repos/git/foo, get the review, >> change it till everybody is satisfied and eventually one of the core >> devs could pull the changes. > > Please explain how the former is harder than the latter. At least it's harder for the contributor. Let's say my new feature is quite complex and needs some time to get it right. With CVS I have to do it in one big step. Till it's not finished and ready for inclusion I simply cannot commit. With git I can commit locally whenever I want. If I have three alternative approaches to handle something I can easily create three local branches and switch between them to test which is better. And if I do somthing stupid (which I always do!) I can easily revert to a previous version. To do something like local branches with CVS I would need to checkout the complete repository several times and still I could not commit to revert after a wrong decision. So currently I make file backups once in a while which is really a pain. > You still need to wait for review and approval. Sure, but as I said, I consider that a good thing. And if the reviewers at the 13th review say that my last changes are completely stupid, I can easily revert to revision 12 if we'd use git or another distributed VCS. > OTOH, having a patch pushed into my INBOX and staring in my face runs > better chances that I will review it than if I need to be on-line and > type some commands first just to see it. Ok, so I'd write a mail with my repository location and a `git diff' output. >> There's a nice video at youtube where Linus Torvalds talks about git >> where he discribes the benefits of distributed VCSs (in a very >> entertaining way). > > Linus and others invented git because Linux kernel development is > radically different from Emacs development. To start using git, we > need first get to the point the Linux kernel developers are at: lots > of developers independently developing all kinds of extensions. Git (and any other distributed VCS) can be used in a CVS style with one main repository without loosing any of its benefits. > _And_ we need a head maintainer who works on nothing else but > integration of features she likes into the product that is eventually > released. I don't see the difference between pulling from somebody (after a review) and applying the patches attached to a mail. Of course the core devs would have write access to the main repository, so all of them could push their own changes into it (plus changes they reviewed from others). So any core dev would be a potential integrator. > Please also don't forget that, unlike a Linux kernel, Emacs must have > good user-level documentation. So decentralized development needs > also solve the problem of producing high quality manuals. I guess that's part of the review. "Hey, nice work. Please come back when the docs are finished." >> IMO this would change with a VCS like git, too. On problem with the >> current situation is that possible contributors might fear that their >> changes break something or won't be liked by the core devs. So they >> don't even try it at all. > > I don't see why. Someone who wants just to try things can do that in > their sandbox; no one will ever know they did it unless they tell or > post the patches. How is this different from using git? As I said above: You can develop in little steps and still use all the benefits a VCS offers (committing, reverting, branching, merging, tagging). >> So to sum up: There are quite a few young devs that write good elisp >> code > > Do you have numbers? or is "few" == 1 here? I know at least two beside me: David O'Toole and Michael Olson. And at least the latter uses git for all his projects. But I'm sure there are many more. Bye, Tassilo ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 8:20 ` Tassilo Horn @ 2008-01-03 9:50 ` Richard Stallman 2008-01-03 13:15 ` Ævar Arnfjörð Bjarmason 0 siblings, 1 reply; 258+ messages in thread From: Richard Stallman @ 2008-01-03 9:50 UTC (permalink / raw) To: Tassilo Horn; +Cc: emacs-devel With git I can commit locally whenever I want. If I have three alternative approaches to handle something I can easily create three local branches and switch between them to test which is better. And if I do somthing stupid (which I always do!) I can easily revert to a previous version. The feature of local branches does sound useful. I don't see the difference between pulling from somebody (after a review) and applying the patches attached to a mail. Is it possible to "pull from somebody" when his machine is not on line? ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-03 9:50 ` Richard Stallman @ 2008-01-03 13:15 ` Ævar Arnfjörð Bjarmason 2008-01-04 13:56 ` Stefan Monnier 0 siblings, 1 reply; 258+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2008-01-03 13:15 UTC (permalink / raw) To: rms; +Cc: Tassilo Horn, emacs-devel Richard Stallman <rms@gnu.org> writes: > The feature of local branches does sound useful. > > I don't see the difference between pulling from somebody (after a > review) and applying the patches attached to a mail. > > Is it possible to "pull from somebody" when his machine > is not on line? Yes, if that person placed (pushed) his changes somewhere before going offline. This could have been been done by sending a patchset generated by git-format-patch to a mailing list, by pushing to a repository that acts as a mirror (repo.or.cz hosts such a service) to name two possibilities. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-03 13:15 ` Ævar Arnfjörð Bjarmason @ 2008-01-04 13:56 ` Stefan Monnier 0 siblings, 0 replies; 258+ messages in thread From: Stefan Monnier @ 2008-01-04 13:56 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason; +Cc: Tassilo Horn, rms, emacs-devel >> The feature of local branches does sound useful. >> >> I don't see the difference between pulling from somebody (after a >> review) and applying the patches attached to a mail. >> >> Is it possible to "pull from somebody" when his machine >> is not on line? > Yes, if that person placed (pushed) his changes somewhere before going > offline. This could have been been done by sending a patchset generated > by git-format-patch to a mailing list, by pushing to a repository that > acts as a mirror (repo.or.cz hosts such a service) to name two > possibilities. It is worth noting also that the repository acting as a mirror can just as well be the main repository: his push just adds a branch and does not affect the "trunk". Stefan ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 20:36 ` Eli Zaretskii 2008-01-02 0:29 ` Miles Bader 2008-01-02 8:20 ` Tassilo Horn @ 2008-01-02 8:41 ` tomas 2 siblings, 0 replies; 258+ messages in thread From: tomas @ 2008-01-02 8:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Tassilo Horn, emacs-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Jan 01, 2008 at 10:36:30PM +0200, Eli Zaretskii wrote: > > From: Tassilo Horn <tassilo@member.fsf.org> [...] > > IMO this would change with a VCS like git, too. On problem with the > > current situation is that possible contributors might fear that their > > changes break something or won't be liked by the core devs. So they > > don't even try it at all. > > I don't see why. Someone who wants just to try things can do that in > their sandbox; no one will ever know they did it unless they tell or > post the patches. How is this different from using git? To paraphrase what Tassilo has written elsewhere in this thread: the potential contributor will be able to survive the time in which his potential patches aren't integrated yet -- even pulling in changes made to the main line. With CVS this is @#&%^H^H^H^Hdaunting. Two recent examples: multy-tty and unicode. And even there, we are benefitting from a distributed version control system, Arch, with a friendly user interface put on top (named Miles :-) Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFHe04nBcgs9XrR2kYRAijpAJ9FcCi2pUF7LT4q2PCrrprawIDQlACcDaNX oJAv/TTBq/vMkJv0Kv4wTts= =WJ5S -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 11:28 ` Tassilo Horn 2008-01-01 20:36 ` Eli Zaretskii @ 2008-01-03 9:50 ` Richard Stallman 2008-01-03 10:16 ` Miles Bader 2008-01-03 10:32 ` David Kastrup 1 sibling, 2 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-03 9:50 UTC (permalink / raw) To: Tassilo Horn; +Cc: emacs-devel There would be no need to have write access at all. I can alway commit to my repository (even when I'm offline, a fact that should be a big plus for Richard) and synching happens whenever something important has be done and some core dev reviewed it. I am having trouble understanding what it _means_ to say that you can do a "commit" into your own repository. That must be something very different from a "commit" in CVS terms. Perhaps it is so different that the two are not comparable at all. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-03 9:50 ` Richard Stallman @ 2008-01-03 10:16 ` Miles Bader 2008-01-05 5:55 ` Richard Stallman 2008-01-03 10:32 ` David Kastrup 1 sibling, 1 reply; 258+ messages in thread From: Miles Bader @ 2008-01-03 10:16 UTC (permalink / raw) To: rms; +Cc: Tassilo Horn, emacs-devel Richard Stallman <rms@gnu.org> writes: > I am having trouble understanding what it _means_ to say that you can > do a "commit" into your own repository. That must be something very > different from a "commit" in CVS terms. Perhaps it is so different that > the two are not comparable at all. Basically, in git (and many other systems), _every working directory_ contains its own repository, stored in the ".git" subdirectory. .git contains the entire history of the project, which is why you can examine log entries and old versions without being connected; it is highly compressed so for instance in the case of Emacs, .git takes only a little more space than the source tree itself. When you commit using "git commit", you're committing to the .git subdirectory. So "git commit" means "WD changes -> .git", a local operation. Git then contains commands to merge between repositories (either "pushing" or "pulling" to/from another repository). You can push or pull to remote repositories as well as local ones (a remote repository, might be like "ssh://git.sv.gnu.org/srv/git/emacs.git", whereas local repository is simply another git working directory [containing it's own .git subdir]). So perhaps you hack all day, periodically making commits (using "git commit") which store your changes into the .git subdir. Then when you later connect to the net, you can merge the new changes in .git into the remote emacs repository on savannah (using "git push"). -Miles -- Suburbia: where they tear out the trees and then name streets after them. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-03 10:16 ` Miles Bader @ 2008-01-05 5:55 ` Richard Stallman 2008-01-05 6:59 ` Óscar Fuentes ` (3 more replies) 0 siblings, 4 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-05 5:55 UTC (permalink / raw) To: Miles Bader; +Cc: tassilo, emacs-devel So perhaps you hack all day, periodically making commits (using "git commit") which store your changes into the .git subdir. Then when you later connect to the net, you can merge the new changes in .git into the remote emacs repository on savannah (using "git push"). It sounds like "git push" is the real analogue of CVS commit, and that this is the closest match-up between the concepts of git and the concepts of CVS: CVS GIT save file = commit commit = pull or push But I still don't understand what step actually alters the trunk that users will get by default from the public repository. Does `push' do that? If not `push', then what? ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 5:55 ` Richard Stallman @ 2008-01-05 6:59 ` Óscar Fuentes 2008-01-05 15:29 ` Eli Zaretskii 2008-01-06 8:09 ` Richard Stallman 2008-01-05 8:55 ` David Kastrup ` (2 subsequent siblings) 3 siblings, 2 replies; 258+ messages in thread From: Óscar Fuentes @ 2008-01-05 6:59 UTC (permalink / raw) To: emacs-devel; +Cc: Richard Stallman Richard Stallman <rms@gnu.org> writes: > So perhaps you hack all day, periodically making commits (using "git > commit") which store your changes into the .git subdir. Then when you > later connect to the net, you can merge the new changes in .git into the > remote emacs repository on savannah (using "git push"). > > It sounds like "git push" is the real analogue of CVS commit, > and that this is the closest match-up between the concepts of git > and the concepts of CVS: > > CVS GIT > save file = commit > commit = pull or push > > But I still don't understand what step actually alters the trunk that > users will get by default from the public repository. Does `push' do > that? If not `push', then what? The basis of DVCSs is that every user has one (or more) personal repositories. You work on your own for a period of time as if you were the only one on the project, committing changes to your repository. Then, you decide to share your changes with the rest of the world. For this, you "push" the changes to the "golden" central repository, where other users "pull" them to update their personal repositories. It's just a matter of independent repositories that communicates with each other. "Push" is "send my changes" and "pull" is "get other's changes". Using analogies with CVS here is dangerous and only help to obscure what a DVCS is. As is the case with learning a new programming language, it's better to forget about specific languages you know and think on terms of how useful the language is for you. Often you see that the new language is a big improvement because it solves a problem that you didn't realized until you see it solved. A very important feature is that you are not limited to communicate with the central repository. You can make available your personal repository to other users and so create groups of developers working together on a issue. When the work is done, some of you push the final result into the central repository. Personal repositories and peer-to-peer sharing opens lots of possibilities: you can work on a difficult issue using localy the advantages of having a personal VCS, doing multiple commits as you hack the problem and, finally, "pushing" to the central repository the clean, finished work. As mentioned above, you can share your changes with other people without touching the central repository. You can create as much personal branches as needed for your personal use, as this is a local operation. In fact, some DVCS encourage branching even to implement almost trivial changes, which makes much sense if you ever work on more than one issue at the same time. When your repository communicates with other repo, either by getting (pulling) or by sending (pushing) changesets, a merge is performed. DVCSs uses sophisticated algorithms for tracking merges and remembers which changesets are already merged on every repository. It is possible to get or send a selection of changesets on a consistent way (this is termed cherry-picking), that is, if you require changeset 100 and it depends on changeset 93, the system knows this and takes the appropiate action. -- Oscar ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 6:59 ` Óscar Fuentes @ 2008-01-05 15:29 ` Eli Zaretskii 2008-01-05 19:53 ` Óscar Fuentes 2008-01-06 8:09 ` Richard Stallman 1 sibling, 1 reply; 258+ messages in thread From: Eli Zaretskii @ 2008-01-05 15:29 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > From: =?iso-8859-1?Q?=D3scar_Fuentes?= <ofv@wanadoo.es> > Date: Sat, 05 Jan 2008 07:59:07 +0100 > Cc: Richard Stallman <rms@gnu.org> > > Using analogies with CVS here is dangerous and only help to obscure what > a DVCS is. This cannot be helped, and resisting this tendency will only obstruct constructive dialog. People understand new things by analogies to something they already know; this is how we synthesize new knowledge and ideas. > Personal repositories and peer-to-peer sharing opens lots of > possibilities: you can work on a difficult issue using localy the > advantages of having a personal VCS, doing multiple commits as you hack > the problem and, finally, "pushing" to the central repository the clean, > finished work. As mentioned above, you can share your changes with other > people without touching the central repository. Are there any tools or widely-accepted methods for figuring out what is the main "theme" of a certain branch of a given personal repository? Or does Joe Random Hacker still need to use email to find out what is available out there? ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 15:29 ` Eli Zaretskii @ 2008-01-05 19:53 ` Óscar Fuentes 0 siblings, 0 replies; 258+ messages in thread From: Óscar Fuentes @ 2008-01-05 19:53 UTC (permalink / raw) To: emacs-devel; +Cc: Eli Zaretskii Eli Zaretskii <eliz@gnu.org> writes: > Are there any tools or widely-accepted methods for figuring out what > is the main "theme" of a certain branch of a given personal > repository? Or does Joe Random Hacker still need to use email to find > out what is available out there? A local repository is just a directory somewhere on your filesystem. As such, it has a name chosen by you. A published repository is an URL that points to some local repository. Giving meaningful names is up to you. The users that you allow to access your repositories can remotely inspect the logs and so gain more info about your hacking. Usually, you'll say to your intended audience "I'm implementing feature X and you can follow my work on protocol://my.domain/myrepos/featureX" -- Oscar ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 6:59 ` Óscar Fuentes 2008-01-05 15:29 ` Eli Zaretskii @ 2008-01-06 8:09 ` Richard Stallman 1 sibling, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-06 8:09 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Using analogies with CVS here is dangerous and only help to obscure what a DVCS is. You may be right. My point is that the use of the word "commit" to describe one DVS operation does itself make an analogy with CVS. I found that analogy misleading. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 5:55 ` Richard Stallman 2008-01-05 6:59 ` Óscar Fuentes @ 2008-01-05 8:55 ` David Kastrup 2008-01-05 9:55 ` Werner LEMBERG ` (2 more replies) 2008-01-05 22:46 ` Stefan Monnier 2008-01-07 17:17 ` Gregory Collins 3 siblings, 3 replies; 258+ messages in thread From: David Kastrup @ 2008-01-05 8:55 UTC (permalink / raw) To: rms; +Cc: tassilo, emacs-devel, Miles Bader Richard Stallman <rms@gnu.org> writes: > So perhaps you hack all day, periodically making commits (using "git > commit") which store your changes into the .git subdir. Then when you > later connect to the net, you can merge the new changes in .git into the > remote emacs repository on savannah (using "git push"). > > It sounds like "git push" is the real analogue of CVS commit, No. Pushing works between repositories. It is the way to propagate changes to others. > and that this is the closest match-up between the concepts of git > and the concepts of CVS: > > CVS GIT > save file = commit No. Saving a file will not give you all the version control history and tools and diffs and branching and other tools that committing does under git. You have all that working machinery to your disposal once you have committed. Pushing just pushes out your commits (and not just a snapshot) to the remote repository. It does not change what you are working with. Your own repository and workflow is not affected. You never need to push in order to get something into better working order for yourself. Note that while you have not pushed out anything, git has a variety of tools for rewriting and cleaning up your own branches/repository. In that manner, a new feature usually arrives in one coherent series of commits. Also, if you are developing a new feature, you need not push it out to the central repository, but can still share the development with a private set of other people. > commit = pull or push > > But I still don't understand what step actually alters the trunk that > users will get by default from the public repository. Does `push' do > that? If not `push', then what? Pushing will, yes. The act of pushing will make the remote trunk assume the state of the current trunk (without dropping changes only available in the remote trunk: in that case, git requires you to pull and merge those first). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 8:55 ` David Kastrup @ 2008-01-05 9:55 ` Werner LEMBERG 2008-01-05 15:23 ` Eli Zaretskii 2008-01-06 8:09 ` Richard Stallman 2 siblings, 0 replies; 258+ messages in thread From: Werner LEMBERG @ 2008-01-05 9:55 UTC (permalink / raw) To: dak; +Cc: tassilo, miles, rms, emacs-devel > > It sounds like "git push" is the real analogue of CVS commit, > > No. Pushing works between repositories. It is the way to propagate > changes to others. This fundamental difference between CVS and git was the hardest point for me in understanding the mechanisms. Werner ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 8:55 ` David Kastrup 2008-01-05 9:55 ` Werner LEMBERG @ 2008-01-05 15:23 ` Eli Zaretskii 2008-01-05 15:31 ` Lars Magne Ingebrigtsen 2008-01-05 15:39 ` David Kastrup 2008-01-06 8:09 ` Richard Stallman 2 siblings, 2 replies; 258+ messages in thread From: Eli Zaretskii @ 2008-01-05 15:23 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel > From: David Kastrup <dak@gnu.org> > Date: Sat, 05 Jan 2008 09:55:57 +0100 > Cc: tassilo@member.fsf.org, emacs-devel@gnu.org, Miles Bader <miles@gnu.org> > > > CVS GIT > > save file = commit > > No. Saving a file will not give you all the version control history and > tools and diffs and branching and other tools that committing does under > git. What tools and diffs are those? So far, AFAIU, the only difference between save-file and GIT commit is that with the latter, you can start a (local) branch. If there are other reasons for local commits, what are they? ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 15:23 ` Eli Zaretskii @ 2008-01-05 15:31 ` Lars Magne Ingebrigtsen 2008-01-05 15:39 ` David Kastrup 1 sibling, 0 replies; 258+ messages in thread From: Lars Magne Ingebrigtsen @ 2008-01-05 15:31 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > What tools and diffs are those? So far, AFAIU, the only difference > between save-file and GIT commit is that with the latter, you can > start a (local) branch. If there are other reasons for local commits, > what are they? Well, it's, like, a commit. :-) That is, it's a unit of work committed to the repository. You have a commit log message, and the unit can either be applied or reverted. Let's say you're working offline on the file foo.el. First you fix a bug dealing with issue A, and you commit that to the repository. Then you fix another, totally different bug, dealing with issue B, and you commit that. When you come online, you "push" these commits to the central repository, which will see these two changes as two separate changes, not just a single change. If you're not online all the time, having a distributed SCM can be liberating for your work flow. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 15:23 ` Eli Zaretskii 2008-01-05 15:31 ` Lars Magne Ingebrigtsen @ 2008-01-05 15:39 ` David Kastrup 1 sibling, 0 replies; 258+ messages in thread From: David Kastrup @ 2008-01-05 15:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: David Kastrup <dak@gnu.org> >> Date: Sat, 05 Jan 2008 09:55:57 +0100 >> Cc: tassilo@member.fsf.org, emacs-devel@gnu.org, Miles Bader <miles@gnu.org> >> >> > CVS GIT >> > save file = commit >> >> No. Saving a file will not give you all the version control history and >> tools and diffs and branching and other tools that committing does under >> git. > > What tools and diffs are those? So far, AFAIU, the only difference > between save-file and GIT commit is that with the latter, you can > start a (local) branch. If there are other reasons for local commits, > what are they? Being able to start a local branch at the drop of a hat is actually very very valuable. Anyway: You can diff between any committed versions. You can revert particular commits. You can checkout any previous version by date or version. Branching is actually quite important since you can work on several unfinished projects at once, deciding for yourself when and how you merge in upstream changes to keep your branch abreast. You can make a bloody mess of your repository and back out again (it is actually rather hard to really lose any history with git) without anybody else noticing. You can merge in a particular patch set from somebody else. If you notice a regression, you can create a test case for it and let git automatically biject from your local branch history until it pinpoints what commit has been responsible for the regression. Once you think you have reached a good state of your local branch, you can clean up and merge and reorder the commits into sensible order, and then push or offer them as a coherent, well-organized set of commits (so there is no need for something like a ChangeLog cleanup) on top of some externally available branch. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 8:55 ` David Kastrup 2008-01-05 9:55 ` Werner LEMBERG 2008-01-05 15:23 ` Eli Zaretskii @ 2008-01-06 8:09 ` Richard Stallman 2008-01-06 9:51 ` tomas 2008-01-06 11:02 ` David Kastrup 2 siblings, 2 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-06 8:09 UTC (permalink / raw) To: David Kastrup; +Cc: tassilo, emacs-devel, miles > It sounds like "git push" is the real analogue of CVS commit, No. Pushing works between repositories. It is the way to propagate changes to others. At this level, that's just a detail. The must important thing about CVS commit is that it alters what other people will get if they ask to get the current version from the repository. With git, the operation which does that is `push'. > CVS GIT > save file = commit No. Saving a file will not give you all the version control history and tools and diffs and branching and other tools that committing does under git. Ok, but those are details. The crucial point is that saving a file, or git commit, alters your own data only; it does not affect what other users will get from the published repository. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-06 8:09 ` Richard Stallman @ 2008-01-06 9:51 ` tomas 2008-01-06 11:02 ` David Kastrup 1 sibling, 0 replies; 258+ messages in thread From: tomas @ 2008-01-06 9:51 UTC (permalink / raw) To: Richard Stallman; +Cc: miles, tassilo, emacs-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Jan 06, 2008 at 03:09:19AM -0500, Richard Stallman wrote: [...] > Ok, but those are details. The crucial point is that saving a file, > or git commit, alters your own data only; it does not affect what > other users will get from the published repository. Yes and no. That depends on wether "your" repository is the one other users refer to (a perfectly valid setup under Arch and git -- and I guess under other distributed VCSes as well). Not that this would be a good idea for a "big" and "loosely-knit" project, though. So it's rather that the "commit" of central VCSese is split up into two operations (commit: working dir --> repo; push: repo --> repo) in distributed VCSes. On a central VCS, with just one repo, this differentiation doesn't make kuch sense. The analogy suggested by re-using commit is quite valid, and afaik all distributed VCSes went this path (so it seems to be rather compelling). Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFHgKSGBcgs9XrR2kYRAj69AJ47F1Dlg0BxgKL0o5QC7Nf1LAu+qgCeI6gA z2L3J0oMelDI70EyqYnddXU= =niBM -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-06 8:09 ` Richard Stallman 2008-01-06 9:51 ` tomas @ 2008-01-06 11:02 ` David Kastrup 2008-01-06 12:05 ` Robert J. Chassell 1 sibling, 1 reply; 258+ messages in thread From: David Kastrup @ 2008-01-06 11:02 UTC (permalink / raw) To: rms; +Cc: tassilo, emacs-devel, miles Richard Stallman <rms@gnu.org> writes: > > It sounds like "git push" is the real analogue of CVS commit, > > No. Pushing works between repositories. It is the way to propagate > changes to others. > > At this level, that's just a detail. The must important thing about > CVS commit is that it alters what other people will get if they ask to > get the current version from the repository. With git, the operation > which does that is `push'. Not really. The atomic operation changing a repository is a commit which is a commented and registered snapshot of a complete work tree with a pointer to its parent commit (or in the case of a merge, all of its parents). And a commit may make it into a repository rather equivalently by doing a commit from a work directory, by applying a patch or patch series, or by pushing/pulling between repositories. > > CVS GIT > > save file = commit > > No. Saving a file will not give you all the version control history and > tools and diffs and branching and other tools that committing does under > git. > > Ok, but those are details. The crucial point is that saving a file, > or git commit, alters your own data only; it does not affect what > other users will get from the published repository. Unless your "own data" _is_ the published repository. Which is pretty common the case for projects with an official repository controlled by one or few persons, like the Linux kernel. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-06 11:02 ` David Kastrup @ 2008-01-06 12:05 ` Robert J. Chassell 2008-01-06 12:40 ` David Kastrup 0 siblings, 1 reply; 258+ messages in thread From: Robert J. Chassell @ 2008-01-06 12:05 UTC (permalink / raw) To: emacs-devel Unless your "own data" _is_ the published repository. But in Emacs development, it is not. As an example, consider a Medieval European merchant: he thought of a trading voyage to Constantinople as `his'. Several centuries later, a merchant thought of a trading voyage as `not his' even if he owned the ship 100%, did not purchase insurance, etc. That is because of a change in book keeping in which a distinction was made between those who controlled money and their nephews and cousins who went on the voyage. (I think the then new book keeping was intended to make it harder for the nephews and cousins to steal excessively; but that is neither here nor there.) I, for one, do not want to use RMS's repository. For one, he is often off-line. I prefer a site that is supposed to be on-line when I try to connect. No one is defending CVS; but several want to understand how to be the equivalent of what they are already, a 16th century merchant, rather than a 12th century merchant. That is what this whole `commit', `push' discussion is about. Since some developers have work and sleep patterns that are 12 hours different from yours, and they do not want you to change to confirm to them, they do not want anything that is immediate. And some are not connected and some do not want interruptions. IRC is big fear, since it means that some people will not develop and there are few as it is. That means email makes sense. -- Robert J. Chassell GnuPG Key ID: 004B4AC8 bob@rattlesnake.com bob@gnu.org http://www.rattlesnake.com http://www.teak.cc ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-06 12:05 ` Robert J. Chassell @ 2008-01-06 12:40 ` David Kastrup 2008-01-06 16:51 ` Robert J. Chassell 2008-01-07 4:18 ` Richard Stallman 0 siblings, 2 replies; 258+ messages in thread From: David Kastrup @ 2008-01-06 12:40 UTC (permalink / raw) To: bob; +Cc: emacs-devel "Robert J. Chassell" <bob@rattlesnake.com> writes: > Unless your "own data" _is_ the published repository. > > But in Emacs development, it is not. Emacs is not maintained with git (well, git being decentral, everybody is free to work with it regardless). > No one is defending CVS; but several want to understand how to be the > equivalent of what they are already, a 16th century merchant, rather > than a 12th century merchant. That is what this whole `commit', > `push' discussion is about. > > Since some developers have work and sleep patterns that are 12 hours > different from yours, and they do not want you to change to confirm to > them, they do not want anything that is immediate. > > And some are not connected and some do not want interruptions. > > IRC is big fear, since it means that some people will not develop and > there are few as it is. > > That means email makes sense. Well, your above Email doesn't. CVS does not work by Email, git does not work by IRC, and neither are in any manner even remotely related with medieval merchants. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-06 12:40 ` David Kastrup @ 2008-01-06 16:51 ` Robert J. Chassell 2008-01-06 17:03 ` David Kastrup 2008-01-07 4:18 ` Richard Stallman 1 sibling, 1 reply; 258+ messages in thread From: Robert J. Chassell @ 2008-01-06 16:51 UTC (permalink / raw) To: emacs-devel David Kastrup <dak@gnu.org> said Emacs is not maintained with git ... No, it is not. RMS and many others obtain Emacs via CVS, but they or he want to understand a newer version control system. My Medieval merchants example was about understanding CVS and newer version control systems. And, as I said, people want `to be the equivalent of what they are already' which in one case is to be in the 16th century and in the other is to be in the present. CVS does not work by Email ... Right, it does not. In other paragraphs, I talked about email. Comments, like yours, come via email. In those paragraphs, I talked about the fear that some would be excluded because at times they are disconnected from the net, don't want interruptions, or don't want you to adapt your work and sleep pattern to them. -- Robert J. Chassell GnuPG Key ID: 004B4AC8 bob@rattlesnake.com bob@gnu.org http://www.rattlesnake.com http://www.teak.cc ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-06 16:51 ` Robert J. Chassell @ 2008-01-06 17:03 ` David Kastrup 0 siblings, 0 replies; 258+ messages in thread From: David Kastrup @ 2008-01-06 17:03 UTC (permalink / raw) To: bob; +Cc: emacs-devel "Robert J. Chassell" <bob@rattlesnake.com> writes: > David Kastrup <dak@gnu.org> said > > CVS does not work by Email ... > > Right, it does not. In other paragraphs, I talked about email. > Comments, like yours, come via email. > > In those paragraphs, I talked about the fear that some would be > excluded because at times they are disconnected from the net, don't > want interruptions, or don't want you to adapt your work and sleep > pattern to them. And CVS, which requires a constant net connection for working or comparing with anything but the currently checked-out work copy, is supposed to be less worrisome than a system where you can work with your own private repository off-line, including all the diff and branching machinery? You are flaunting a fundamental weakness of CVS (and other centralized SCMs) in _support_ of it? I am afraid that I still can't read any sense into your argument. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-06 12:40 ` David Kastrup 2008-01-06 16:51 ` Robert J. Chassell @ 2008-01-07 4:18 ` Richard Stallman 1 sibling, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-07 4:18 UTC (permalink / raw) To: David Kastrup; +Cc: bob, emacs-devel Well, your above Email doesn't. CVS does not work by Email, git does not work by IRC, and neither are in any manner even remotely related with medieval merchants. Using IRC to communicate was part of method that ESR wanted us to adopt. I agree we can separate that issue from use of a DVCS. The medieval merchants are an analogy; if you take it literally then you don't get the point. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 5:55 ` Richard Stallman 2008-01-05 6:59 ` Óscar Fuentes 2008-01-05 8:55 ` David Kastrup @ 2008-01-05 22:46 ` Stefan Monnier 2008-01-06 18:09 ` Richard Stallman 2008-01-07 17:17 ` Gregory Collins 3 siblings, 1 reply; 258+ messages in thread From: Stefan Monnier @ 2008-01-05 22:46 UTC (permalink / raw) To: rms; +Cc: tassilo, emacs-devel, Miles Bader > So perhaps you hack all day, periodically making commits (using "git > commit") which store your changes into the .git subdir. Then when you > later connect to the net, you can merge the new changes in .git into the > remote emacs repository on savannah (using "git push"). > It sounds like "git push" is the real analogue of CVS commit, > and that this is the closest match-up between the concepts of git > and the concepts of CVS: > CVS GIT > save file = commit > commit = pull or push Kind of, yes, except that the "git commit" really does a "local commit" to a local branch. In VC we implemented a poor-man replacement by allowing mixing various backends, where the expected use was as follows: Let's say you have a file under CVS which you want to modify. The modifications are fairly long running and you feel like you'd want to be able to commit every once in a while so you can go back or so you can diff between various intermediate stages of your work. But as it turns out you don't actually want to commit to the CVS either because the CVS repository is unavailable (offline, or read-only), or because you're not sure you'll want to install the change in the end, or ... So you register your file under RCS: the file is now both under CVS and under RCS at the same time. C-x v b allows you to switch VC's view between the two backends. So now you can do all your local commits to RCS, with ability to do diffs/revert/... without needing to contact the CVS repository. After a while, your hacking may result in something you decide deserves to make it into the CVS, so you go ahead and commit the new file to CVS. VC actually provides you with a command that makes up the changelog for this commit by extracting it from the RCS file, thus basically transfering the local RCS branch to the CVS repository (as a single change rather than a bunch of little changes). In the above context, the equivalence would be: CVS&RCS Git save file save file commit to RCS commit commit to CVS push > But I still don't understand what step actually alters the trunk that > users will get by default from the public repository. Does `push' do > that? Yes, presuming that by "push" you mean "push to the default public repository". Stefan ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 22:46 ` Stefan Monnier @ 2008-01-06 18:09 ` Richard Stallman 0 siblings, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-06 18:09 UTC (permalink / raw) To: Stefan Monnier; +Cc: tassilo, emacs-devel, miles > But I still don't understand what step actually alters the trunk that > users will get by default from the public repository. Does `push' do > that? Yes, presuming that by "push" you mean "push to the default public repository". In CVS terms, that's commit. To make a useful comparison between CVS and git, we should think of this as "conceptual commit", even though it is not called "commit" in git terminology. Thus, I think that the relationship between merging and conceptual commit is the same in git as it is in CVS. In both cases you have to merge first before you do the conceptual commit. In the above context, the equivalence would be: CVS&RCS Git save file save file commit to RCS commit commit to CVS push That seems like a good explanation too. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 5:55 ` Richard Stallman ` (2 preceding siblings ...) 2008-01-05 22:46 ` Stefan Monnier @ 2008-01-07 17:17 ` Gregory Collins 2008-01-07 23:21 ` Stephen J. Turnbull 2008-01-08 19:07 ` Richard Stallman 3 siblings, 2 replies; 258+ messages in thread From: Gregory Collins @ 2008-01-07 17:17 UTC (permalink / raw) To: rms; +Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > It sounds like "git push" is the real analogue of CVS commit, and that > this is the closest match-up between the concepts of git and the > concepts of CVS: > > CVS GIT > save file = commit > commit = pull or push > > But I still don't understand what step actually alters the trunk that > users will get by default from the public repository. Does `push' do > that? If not `push', then what? The discussion thusfar has been centred on the nuts and bolts of distributed version control, and I think the point that's getting overlooked is that decentralization allows you to arbitrarily redefine the topology of how change flows through a project. To make this more concrete, here are some commonly-used workflow models: 1. CVS-style / star topology ---------------------------- There is a centralized "one true repository" at a known location (e.g. http://savannah.gnu.org/.../hg/emacs-trunk). A medium-sized group of hackers have "push" rights there. (It's the "push" that alters the trunk here.) This approach doesn't scale well, although for emacs the commit rate is probably low enough that this topology is manageable. (That said, how many times have you asked "who committed this wonky change that broke X?" this year?) 2. "Lieutenant" / "subsystem percolation" ------------------------------------------ There is a "canonical" version of emacs that lives on savannah. (This is always true so I'll stop mentioning it.) The project is split by subsystem (and possibly is split further, resulting in a tree structure), and for each a maintainer keeps a source tree with changes to that given subsystem. When two subsystems need to be updated simultaneously due to an interface change, the lieutenants coordinate amongst themselves, pulling changes between each other. When a change is deemed ready to go to trunk (or to a parent node in the tree), the upstream maintainer pulls these changes into her tree. Note here that changes are only pulled, never pushed. Very often, subsystem maintainers "merge down" changes from trunk, so that bugfixes/stable new features from other branches are continually integrated. Everyone works hard to ensure that changes don't break anything upstream. (cf. the ongoing VC-mode restructuring; under this scheme those changes would not have been pushed to trunk until they were complete and tested.) This approach scales VERY well (it's what linux-kernel uses, and their code churn rate is *incredible*) but is probably wrong for emacs. 3. Mailing list w/ gatekeeper(s) --------------------------------- This is how mercurial manages its own development. Proposed changes are sent in patch form to a mailing list, which is dedicated to the discussion and review of such patches. The central repository is read-only except for a small set of integrators. When a change has been reviewed + tested, an integration crew member pulls the patch from email into the central tree. This is the approach I'd suggest for emacs (and it's the one we instituted for the project I maintain at my workplace). The main advantages: - code gets reviewed by more eyes. Cf. the emacs-devel+emacs-commit lists; it's my observation that bad changes are often discussed + reviewed AFTER they've been committed to the trunk. How many questionable or marginal changes are slipping by, do you think? - VC tools streamline the process of sending + reviewing changes. I can type "hg email tip" from my working branch to send my last changeset to the list for discussion. On the negative side, this approach becomes asymptotically less efficient as the number of patches per day increases. However: the beauty of distributed version control is that you can rework your topology at will. To get a flavour for how this process works from a cultural standpoint, you can read the mercurial-devel mailing list archive at: http://selenic.com/pipermail/mercurial-devel/ Thanks, Gregory Collins <greg@maptuit.com> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 17:17 ` Gregory Collins @ 2008-01-07 23:21 ` Stephen J. Turnbull 2008-01-08 0:25 ` Gregory Collins 2008-01-08 19:07 ` Richard Stallman 1 sibling, 1 reply; 258+ messages in thread From: Stephen J. Turnbull @ 2008-01-07 23:21 UTC (permalink / raw) To: Gregory Collins; +Cc: rms, emacs-devel Gregory Collins writes: > To make this more concrete, here are some commonly-used workflow models: I think this discussion is premature. Richard has indicated that he is satisfied that the Hippocratic Principle ("First, do no harm") *can* be satisfied by both a bug tracker and a dVCS. Further, he acknowledges that their potential benefits are significant *in the current workflow*. However, he expresses reservations that particular tools may still be detrimental to the Emacs project's productivity, if badly implemented. He's absolutely right. Thus I suggest that the project workflow discussion be postponed until the core stakeholders are satisfied that the new tools are functioning stably in the current workflow. This will take only a month, at most two, once the tools are chosen. As you point out, a big advantage of a dVCS is the flexibility of the workflow even after it is installed. There is no big loss to waiting a bit, and a potential large gain: the improved understanding of the tools that the core stakeholders will have. This doesn't mean that those who want to implement other workflows have to wait, with nothing to do. Find other developers of like mind and start experimenting "off the main workflow". Cf. Miles's Arch repo, which is already providing substantial efficiencies in branch synchronization. I'm sure David Kastrup, for another, will be able to use a dVCS to good effect in supporting AUCTeX (which AIUI cannot yet be merged into Emacs because of legal considerations). Regarding the example workflows: > 1. CVS-style / star topology > ---------------------------- > There is a centralized "one true repository" at a known location > (e.g. http://savannah.gnu.org/.../hg/emacs-trunk). A medium-sized group > of hackers have "push" rights there. (It's the "push" that alters the > trunk here.) > > This approach doesn't scale well, although for emacs the commit rate is > probably low enough that this topology is manageable. (That said, how > many times have you asked "who committed this wonky change that broke > X?" this year?) At Emacs scale, the scaling problem here is the combination of lack of a testing framework and the star topology, not just the star topology. Python does fine with a star topology at a similar scale to Emacs, I would say. Since this *is* the current workflow, and changing to a dVCS (by itself) will not immediately increase the patch flow by anything like an order of magnitude, things will not get worse if this workflow is continued across the change in tools. > 2. "Lieutenant" / "subsystem percolation" > ------------------------------------------ > There is a "canonical" version of emacs that lives on savannah. (This is > always true so I'll stop mentioning it.) The project is split by > subsystem (and possibly is split further, resulting in a tree > structure), and for each a maintainer keeps a source tree with changes > to that given subsystem. When two subsystems need to be updated > simultaneously due to an interface change, the lieutenants coordinate > amongst themselves, pulling changes between each other. > > When a change is deemed ready to go to trunk (or to a parent node in the > tree), the upstream maintainer pulls these changes into her tree. Note > here that changes are only pulled, never pushed. > > Very often, subsystem maintainers "merge down" changes from trunk, so > that bugfixes/stable new features from other branches are continually > integrated. Everyone works hard to ensure that changes don't break > anything upstream. (cf. the ongoing VC-mode restructuring; under this > scheme those changes would not have been pushed to trunk until they were > complete and tested.) > > This approach scales VERY well (it's what linux-kernel uses, and their > code churn rate is *incredible*) but is probably wrong for emacs. This is the only workflow that can scale with a lack of a formal testing framework, but then it doesn't scale for the *people*. It is incredibly hard on the maintainers, and is only really justified where automated testing is hard to do. For Emacs in particular, at least two of the central maintainers (Richard for all of Emacs and Alan MacKenzie for CC Mode) would be potential bottlenecks because of their personal workflows. Also, several others of the plausible subsystem maintainers have expressed misgivings which might imply that they are not interested in functioning as pull-style gatekeepers. Another problem is that all core Emacs developers have areas of interest, but if a prerequisite subsystem for "their" area has a problem, they are used to going in and fixing it unilaterally. This will clash with the "turf rights" that the subsystem maintainers have. Sure, turf rights have been worked out in many cases, such as Gnus and CC Mode, and when conflicts occur, they work out amicably (I'm thinking of recent discussions about refactoring various libraries maintained by the Gnus project into other parts of Emacs when integrated into Emacs). But AIUI in the Linux kernel workflow, the subsystem maintainers have nearly complete hierarchical power over access to parent systems. It *could* work in Emacs, but it will be a change, and I predict it would be a wrenching one. This workflow should therefore be approached with extreme caution by the Emacs developers. > 3. Mailing list w/ gatekeeper(s) > --------------------------------- > This is how mercurial manages its own development. Proposed changes are > sent in patch form to a mailing list, which is dedicated to the > discussion and review of such patches. The central repository is > read-only except for a small set of integrators. When a change has been > reviewed + tested, an integration crew member pulls the patch from email > into the central tree. > > This is the approach I'd suggest for emacs (and it's the one we > instituted for the project I maintain at my workplace). The main > advantages: You're missing an important point: the sheer size and complexity of the Emacs codebase. This requires more *formal* attention to testing than Emacs has historically given it. The problem is that in the Emacs context, a *good* review by the gatekeeper requires a huge stock of knowledge of the codebase plus great expense on *each* patch. Guido van Rossum estimates that a "perfect patch" nonetheless costs him 30-60 minutes, but this is in a context of test-driven development. In Emacs as it stands it will be much greater per patch. If only a small number of gatekeepers have push access to the public repo, it is also a major change in personal workflow for them. Possibly excepting Richard, who IIUC already functions as a sort of Workflow 2 gatekeeper -- except that he doesn't come close to trying to review all patches, even though he is the final authority. This workflow also *should* be viewed with extreme caution by the core developers. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 23:21 ` Stephen J. Turnbull @ 2008-01-08 0:25 ` Gregory Collins 2008-01-08 0:51 ` David Kastrup 0 siblings, 1 reply; 258+ messages in thread From: Gregory Collins @ 2008-01-08 0:25 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > Thus I suggest that the project workflow discussion be postponed until > the core stakeholders are satisfied that the new tools are functioning > stably in the current workflow. This will take only a month, at most > two, once the tools are chosen. As you point out, a big advantage of > a dVCS is the flexibility of the workflow even after it is installed. > There is no big loss to waiting a bit, and a potential large gain: the > improved understanding of the tools that the core stakeholders will > have. Hi Stephen, My remarks weren't meant to urge any immediate course of action, but rather to attempt to broaden the discussion to include possible answers to the question "why would you bother switching?" A discussion that centres on "how do these CVS concepts map to a distributed context?" will tend to obscure the most compelling arguments in favour. Clearly nothing is going to happen in a rush here (nor should it), because even if it's decided that the horse needs a cart, it's going to take months to decide a) what kind of cart b) two wheels or four? c) metal, wood, or composite? d) "what's wrong with saddlebags, anyways?" e) "You guys are soft, I walk everywhere, barefoot" f) "I live in Nunavut, so it's VERY IMPORTANT that the cart have optional skis" ... ad infinitum ... > > 2. "Lieutenant" / "subsystem percolation" > > ------------------------------------------ > > ... > > This is the only workflow that can scale with a lack of a formal > testing framework, but then it doesn't scale for the *people*. It is > incredibly hard on the maintainers, and is only really justified where > automated testing is hard to do. Agreed. > > 3. Mailing list w/ gatekeeper(s) > > --------------------------------- > > ... > > You're missing an important point: the sheer size and complexity of > the Emacs codebase. This requires more *formal* attention to testing > than Emacs has historically given it. The problem is that in the > Emacs context, a *good* review by the gatekeeper requires a huge stock > of knowledge of the codebase plus great expense on *each* patch. > Guido van Rossum estimates that a "perfect patch" nonetheless costs > him 30-60 minutes, but this is in a context of test-driven > development. In Emacs as it stands it will be much greater per patch. If it's a choice between "60 minutes per patch" and "little or no code review at all", I think everyone will agree that the review wouldn't happen. "Formality of code review" is a continuum, however, and it's my experience that you can stop a lot of bugs without pulling out the magnifying glass and tweezers. You may be right that the extreme hairiness of emacs code may invalidate that assumption. I'd argue regardless that the more eyeballs you can get on incoming patches, the better. I'd also argue that despite some impetuous claims to the contrary, the reports of emacs' imminent demise are greatly exaggerated. G. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-08 0:25 ` Gregory Collins @ 2008-01-08 0:51 ` David Kastrup 2008-01-08 2:43 ` Mike Mattie 0 siblings, 1 reply; 258+ messages in thread From: David Kastrup @ 2008-01-08 0:51 UTC (permalink / raw) To: Gregory Collins; +Cc: Stephen J. Turnbull, emacs-devel Gregory Collins <greg@maptuit.com> writes: > I'd also argue that despite some impetuous claims to the contrary, the > reports of emacs' imminent demise are greatly exaggerated. Well, a distributed approach to living would be having a number of bugs crawling about one's corpse. Emacs certainly has no shortage of bugs. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-08 0:51 ` David Kastrup @ 2008-01-08 2:43 ` Mike Mattie 2008-01-08 3:03 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 258+ messages in thread From: Mike Mattie @ 2008-01-08 2:43 UTC (permalink / raw) To: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 1014 bytes --] On Tue, 08 Jan 2008 01:51:23 +0100 David Kastrup <dak@gnu.org> wrote: > Gregory Collins <greg@maptuit.com> writes: > > > I'd also argue that despite some impetuous claims to the contrary, > > the reports of emacs' imminent demise are greatly exaggerated. > > Well, a distributed approach to living would be having a number of > bugs crawling about one's corpse. can't help it, think cells :) you are distributed. Emacs development already uses a distributed version control system. 1. GNU Emacs @ savannah.gnu.org Which is equivalent to the git repository linus-2.6. 2. Emacs.app @ sourceforge.net 3. Carbon Emacs http://homepage.mac.com/zenitani/emacs-e.html 4. Aqua Emacs http://aquamacs.org/ ... others ... Which are equivalent socially to the lieutenant repositories. If you consider each of the CVS branches to be a DVCS repo, there are more as well. Using a tool like git would simply make all of them compatible. > Emacs certainly has no shortage of bugs. > [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-08 2:43 ` Mike Mattie @ 2008-01-08 3:03 ` YAMAMOTO Mitsuharu 2008-01-08 4:25 ` Mike Mattie 0 siblings, 1 reply; 258+ messages in thread From: YAMAMOTO Mitsuharu @ 2008-01-08 3:03 UTC (permalink / raw) To: Mike Mattie; +Cc: emacs-devel >>>>> On Mon, 7 Jan 2008 18:43:52 -0800, Mike Mattie <codermattie@gmail.com> said: > 3. Carbon Emacs http://homepage.mac.com/zenitani/emacs-e.html What's distributed at the above URL is `Carbon Emacs Package', which is based on Carbon Emacs of course, but not Carbon Emacs itself. > 4. Aqua Emacs http://aquamacs.org/ It is `Aquamacs Emacs', also based on Carbon Emacs. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-08 3:03 ` YAMAMOTO Mitsuharu @ 2008-01-08 4:25 ` Mike Mattie 0 siblings, 0 replies; 258+ messages in thread From: Mike Mattie @ 2008-01-08 4:25 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: emacs developers [-- Attachment #1.1: Type: text/plain, Size: 1371 bytes --] On Tue, 08 Jan 2008 12:03:19 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: > >>>>> On Mon, 7 Jan 2008 18:43:52 -0800, Mike Mattie > >>>>> <codermattie@gmail.com> said: > > > 3. Carbon Emacs http://homepage.mac.com/zenitani/emacs-e.html > > What's distributed at the above URL is `Carbon Emacs Package', which > is based on Carbon Emacs of course, but not Carbon Emacs itself. > > > 4. Aqua Emacs http://aquamacs.org/ > > It is `Aquamacs Emacs', also based on Carbon Emacs. you are indeed correct. Those are the pages that I found with google, simply from memory of various Emacs ports I tried for OS X. As far as tools go what about something like emacs.gnu.org ala gcc.gnu.org ? A home for all the various Emacsen trees, plus various elisp efforts not yet merged ? It would certainly facilitate distro packaging to back the projects with GNU quality infrastructure. Considering how special Emacs is within the GNU project I have wondered for a while why the hard work of Emacs developers is currently scattered across such a wide range of sites. EmacsWiki is a godsend but doesn't cut it as a distribution point that distributions like Gentoo can use. Aside from any of the other tools a emacs.gnu.org site would make 2008 a year to toast. > YAMAMOTO Mitsuharu > mituharu@math.s.chiba-u.ac.jp [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 17:17 ` Gregory Collins 2008-01-07 23:21 ` Stephen J. Turnbull @ 2008-01-08 19:07 ` Richard Stallman 1 sibling, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-08 19:07 UTC (permalink / raw) To: Gregory Collins; +Cc: emacs-devel 3. Mailing list w/ gatekeeper(s) --------------------------------- This is how mercurial manages its own development. Proposed changes are sent in patch form to a mailing list, which is dedicated to the discussion and review of such patches. The central repository is read-only except for a small set of integrators. When a change has been reviewed + tested, an integration crew member pulls the patch from email into the central tree. This is the approach I'd suggest for emacs (and it's the one we instituted for the project I maintain at my workplace). The main advantages: I would be willing to try it, or a compromise between this and #1, which would mean a larger number of people who can commit directly to the main repository. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-03 9:50 ` Richard Stallman 2008-01-03 10:16 ` Miles Bader @ 2008-01-03 10:32 ` David Kastrup 1 sibling, 0 replies; 258+ messages in thread From: David Kastrup @ 2008-01-03 10:32 UTC (permalink / raw) To: rms; +Cc: Tassilo Horn, emacs-devel Richard Stallman <rms@gnu.org> writes: > There would be no need to have write access at all. I can alway commit > to my repository (even when I'm offline, a fact that should be a big > plus for Richard) and synching happens whenever something important has > be done and some core dev reviewed it. > > I am having trouble understanding what it _means_ to say that you can > do a "commit" into your own repository. That must be something very > different from a "commit" in CVS terms. Perhaps it is so different that > the two are not comparable at all. No, they are pretty similar, except that everybody has his own private repository. The repositories get synchronized not by commit and checkout (those happen only locally), but by pushing and pulling. These operations are very much optimized to deal with merge conflicts and to figure out what changes were already committed remotely. Apart from "remote tracking branches" which you can set up (but don't need to), the histories of various repositories tend to be different. Before pushing something out (or sending around patches), you will likely "rebase" on the repository your patch is referring to. Rebasing means rewinding the history to a common ancestor, applying all the patches from the remote repository, then reapplying all local patches that are not in the remote repository. Merge conflicts may need to get resolved then. Afterwards, your branch history reads like just your local changes on top of the branch/repo/state you rebased on. One tends to rebase local branches from time to time. For branches which are distributed to others, it is nicer to just merge with other repositories/branches since that saves the others from having to do any rewinds leading to possibly repeated merge resolutions. While you can tell git to keep records of past merge resolutions (so that it will resolve the identical problem automatically the next time), it is nicer not to force this. So basically, commit and checkout (and merges, though with an external source) happen locally. Synchronization with others happens directly between repositories by pushing and pulling, and patch distribution. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 13:07 ` Eric S. Raymond 2007-12-31 20:57 ` Eli Zaretskii @ 2008-01-01 17:11 ` Alan Mackenzie 2008-01-01 18:05 ` Werner LEMBERG ` (2 more replies) 1 sibling, 3 replies; 258+ messages in thread From: Alan Mackenzie @ 2008-01-01 17:11 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Eric S. Raymond, Eli Zaretskii, emacs-devel Hi, Eric! On Mon, Dec 31, 2007 at 08:07:12AM -0500, Eric S. Raymond wrote: > Eli Zaretskii <eliz@gnu.org>: > The old-timers on this list should be asking themselves why, when Emacs > is so undeniably important, it can't attract as many developers as a > mere fantasy game. A few suggestions: o - Emacs is implemented in a wierd special purpose language. o - Emacs is already so good that it's difficult to see room for new features. o - Much core Emacs code has, despite RMS's good sense and emphasis on simplicity, become tortuous and difficult to get into. o - Emacs is a victim of its own success - as its new features make it steadily easier to use, it becomes steadily more intricate and thus harder to learn. A non-user of Emacs cannot become an Emacs hacker. [ .... ] > The Emacs project, though, is still operating at a scale and tempo I > think of as being typical of the late 1980s and early 1990s. I think > we are limited by poor tools, and by habits of thought derived from > those poor tools. Hmmm. There's something ironic about an Emacs developer blaming poor tools. ;-) I'd think it's worth emphasising that CVS is _NOT_ a poor tool; it's an exceptionally flexible, solid and reliable one, free from feature bloat, and I'm grateful indeed to the hackers who've maintained it over the decades. What you mean, Eric, is that CVS is a hammer, and we could now work better by using screws rather than nails. What's the best screwdriver? I've never been able to get excited by VCSs; apart from CVS, I've only had experience with proprietary VCSs, and they have, with one exception, been ghastly. > I'd like to help that change. I'm enthusiastic about this. Go for it, Eric! But I suggest the following two constraints for the new tools, which might not apply to Battle for Wesnoth: o - They must support "batch mode" working, for RMS and others who concentrate fiercely on a single activity at a time. o - They must, like Emacs, be fully usable on a text console without a mouse as well as in X. There are at least 3 hackers here who prefer such a setup. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 17:11 ` Alan Mackenzie @ 2008-01-01 18:05 ` Werner LEMBERG 2008-01-01 18:27 ` Alan Mackenzie ` (2 more replies) 2008-01-01 19:37 ` Eric S. Raymond 2008-01-01 22:01 ` Romain Francoise 2 siblings, 3 replies; 258+ messages in thread From: Werner LEMBERG @ 2008-01-01 18:05 UTC (permalink / raw) To: acm; +Cc: esr, esr, eliz, emacs-devel > [...] I suggest the following two constraints for the new tools, > which might not apply to Battle for Wesnoth: > > o - They must support "batch mode" working, for RMS and others who > concentrate fiercely on a single activity at a time. git has such a batch mode, while CVS has none. So for Richard, git would be a much better choice than CVS since he could commit very small units while being off-line. Werner ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 18:05 ` Werner LEMBERG @ 2008-01-01 18:27 ` Alan Mackenzie 2008-01-01 18:28 ` Werner LEMBERG 2008-01-01 20:53 ` Nick Roberts 2008-01-02 9:53 ` Richard Stallman 2 siblings, 1 reply; 258+ messages in thread From: Alan Mackenzie @ 2008-01-01 18:27 UTC (permalink / raw) To: Werner LEMBERG; +Cc: esr, esr, eliz, emacs-devel Glückwünsch zum Neuen, Werner! On Tue, Jan 01, 2008 at 07:05:35PM +0100, Werner LEMBERG wrote: > > [...] I suggest the following two constraints for the new tools, > > which might not apply to Battle for Wesnoth: > > o - They must support "batch mode" working, for RMS and others who > > concentrate fiercely on a single activity at a time. > git has such a batch mode, while CVS has none. So for Richard, git > would be a much better choice than CVS since he could commit very > small units while being off-line. I don't understand what you mean, here, probably because I don't know git. cvs can work on arbitrary sets of files, e.g. with "cvs update". What do you mean? I was thinking more about the IIRC thingies: If RMS were to take part in online chats, he'd be slowed down to the speed of ordinary hackers, a disastrous loss of productivity for him. (I, of course, would be barely able to keep up. ;-) So, whatever way of discussion we settle on, it must allow people to participate in "batch mode", at their own speed. > Werner -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 18:27 ` Alan Mackenzie @ 2008-01-01 18:28 ` Werner LEMBERG 2008-01-02 9:53 ` Richard Stallman 0 siblings, 1 reply; 258+ messages in thread From: Werner LEMBERG @ 2008-01-01 18:28 UTC (permalink / raw) To: acm; +Cc: esr, esr, eliz, emacs-devel > I don't understand what you mean, here, probably because I don't > know git. cvs can work on arbitrary sets of files, e.g. with "cvs > update". What do you mean? You can commit a change offline (git commit). Later on, when you are online, you say `git pull' to get the current state of the repository, and automatical merging happens (and the usual warnings if there are conflicts). Finally, you say `git push' to synchronize your git repository with the global one. What I like most is that a checked-out git repository is the whole project: You have access to all previous changes ever done -- something CVS doesn't offer. Werner ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 18:28 ` Werner LEMBERG @ 2008-01-02 9:53 ` Richard Stallman 2008-01-02 10:36 ` Werner LEMBERG ` (3 more replies) 0 siblings, 4 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-02 9:53 UTC (permalink / raw) To: Werner LEMBERG; +Cc: esr, acm, eliz, emacs-devel, esr You can commit a change offline (git commit). Later on, when you are online, you say `git pull' to get the current state of the repository, and automatical merging happens (and the usual warnings if there are conflicts). Finally, you say `git push' to synchronize your git repository with the global one. Is this substantially different from CVS, or is it just relabeling? It sounds like `git push' is basically equivalent to CVS commit. With CVS, until you commit your changes, new changes can be installed in the repository, and when you DO get around to committing your changes, you will have to merge them with whatever others have installed. Once you commit, others trying to commit will have the burden of merging their changes with your already-committed changes. With git, I would guess that the same situation obtains until you do `git push' with your changes. Thus, I think that `git push' is the true analogue to CVS commit. This is based on surmise rather than knowledge. If it is wrong, where is the mistake? ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 9:53 ` Richard Stallman @ 2008-01-02 10:36 ` Werner LEMBERG 2008-01-02 12:23 ` Eric S. Raymond 2008-01-04 5:27 ` Richard Stallman 2008-01-02 11:27 ` Thien-Thi Nguyen ` (2 subsequent siblings) 3 siblings, 2 replies; 258+ messages in thread From: Werner LEMBERG @ 2008-01-02 10:36 UTC (permalink / raw) To: rms; +Cc: esr, acm, eliz, emacs-devel, esr [-- Attachment #1: Type: Text/Plain, Size: 1488 bytes --] > You can commit a change offline (git commit). Later on, when > you are online, you say `git pull' to get the current state of > the repository, and automatical merging happens (and the usual > warnings if there are conflicts). Finally, you say `git push' > to synchronize your git repository with the global one. > > Is this substantially different from CVS, or is it just relabeling? > It sounds like `git push' is basically equivalent to CVS commit. Correct. > With CVS, until you commit your changes, new changes can be installed > in the repository, and when you DO get around to committing your > changes, you will have to merge them with whatever others have > installed. Once you commit, others trying to commit will have the > burden of merging their changes with your already-committed changes. This is absolutely the same as with CVS, of course, but: your changes done offline, and which git can add with trivial merging, stay as atomic units. Unfortunately, ChangeLog file are likely to need manual merging each time. Many software projects which use git no longer maintain such a ChangeLog file manually but create it afterwards mechanically. There's a wonderful tool called gitk which enables you to display git changes in a very cleverly manner. However, this is not a TTY application but needs GTK. I don't know whether there exists a gitk equivalent which runs in a terminal. Attached is an image which shows gitk in action. Werner [-- Attachment #2: gitk.png --] [-- Type: Image/Png, Size: 46135 bytes --] [-- Attachment #3: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 10:36 ` Werner LEMBERG @ 2008-01-02 12:23 ` Eric S. Raymond 2008-01-04 5:27 ` Richard Stallman 1 sibling, 0 replies; 258+ messages in thread From: Eric S. Raymond @ 2008-01-02 12:23 UTC (permalink / raw) To: Werner LEMBERG; +Cc: acm, eliz, emacs-devel, rms, esr Werner LEMBERG <wl@gnu.org>: > Attached is an image which shows gitk in action. Other 3G systems have similar tools. I believe there is at least one repo browser that makes a point of supporting three or four of them, which is possible because they're all using the same model of a revision DAG with nodes identified by hashes. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 10:36 ` Werner LEMBERG 2008-01-02 12:23 ` Eric S. Raymond @ 2008-01-04 5:27 ` Richard Stallman 1 sibling, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-04 5:27 UTC (permalink / raw) To: Werner LEMBERG; +Cc: esr, acm, eliz, emacs-devel, esr Attached is an image which shows gitk in action. I looked at it, but I don't understand what i see. I would need someone to show it to me and explain, or perhaps I could figure it out by experimentation on a project whose contents I know. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 9:53 ` Richard Stallman 2008-01-02 10:36 ` Werner LEMBERG @ 2008-01-02 11:27 ` Thien-Thi Nguyen 2008-01-02 12:17 ` Eric S. Raymond 2008-01-03 1:08 ` Giorgos Keramidas 3 siblings, 0 replies; 258+ messages in thread From: Thien-Thi Nguyen @ 2008-01-02 11:27 UTC (permalink / raw) To: rms; +Cc: emacs-devel () Richard Stallman <rms@gnu.org> () Wed, 02 Jan 2008 04:53:40 -0500 This is based on surmise rather than knowledge. If it is wrong, where is the mistake? here is my understanding of the difference(s): cvs commit ~/src/emacs --[net]-> REPO git commit ~/src/emacs --[filesystem]-> ~/src/emacs/.git/REPO git push ~/src/emacs/.git/REPOSITORY --[net]-> REPO thus, to achieve a state where changes are publically accessible, cvs requires one operation, while git two. (i trust the docs others have sent will explain things further, but couldn't resist a little ASCII art... ;--). thi ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 9:53 ` Richard Stallman 2008-01-02 10:36 ` Werner LEMBERG 2008-01-02 11:27 ` Thien-Thi Nguyen @ 2008-01-02 12:17 ` Eric S. Raymond 2008-01-03 1:26 ` Stephen J. Turnbull 2008-01-04 5:27 ` Richard Stallman 2008-01-03 1:08 ` Giorgos Keramidas 3 siblings, 2 replies; 258+ messages in thread From: Eric S. Raymond @ 2008-01-02 12:17 UTC (permalink / raw) To: Richard Stallman; +Cc: acm, eliz, emacs-devel, esr Richard Stallman <rms@gnu.org>: > Is this substantially different from CVS, or is it just relabeling? > It sounds like `git push' is basically equivalent to CVS commit. I have not yet studied git specifically (that's coming after I finish the evaluations on Arch and monotone), but I believe all the modern DVCSes handle this the same way. In my survey paper, I'm calling it the "commit-before-merge" model, as opposed to "merge-before-commit" which is what CVS and Subversion do. It seems to have originated with monotone. CVS and Subversion try to maintain a linear version history unless you do explicit branching. So when you commit a change against an out-of-date revision, they raise a conflict; you have to merge news before being allowed to finish the commit. In modern DVCSes, a push never blocks. The sequence of changesets you developed is grafted into the repo as a branch attached to the revision you pulled from. If no one else has committed or pushed against that revision, the line of development remains linear. If someone has, you have the analogue of a CVS conflict -- the revision is now a branch point with two histories going forward. Later, someone may do a merge operation that fuses those two branches together again. Thus, "commit-before-merge". This is certainly the way monotone, Mercurial, and bzr operate. As I said, I have not yet studied git specifically but I'm pretty sure it works the same way. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 12:17 ` Eric S. Raymond @ 2008-01-03 1:26 ` Stephen J. Turnbull 2008-01-03 2:49 ` Eric S. Raymond 2008-01-04 5:27 ` Richard Stallman 1 sibling, 1 reply; 258+ messages in thread From: Stephen J. Turnbull @ 2008-01-03 1:26 UTC (permalink / raw) To: esr; +Cc: acm, eliz, Richard Stallman, esr, emacs-devel *sigh* And I just finished writing a private message saying I didn't want to get involved. Eric S. Raymond writes: > CVS and Subversion try to maintain a linear version history unless you > do explicit branching. So when you commit a change against an out-of-date > revision, they raise a conflict; you have to merge news before being > allowed to finish the commit. > > In modern DVCSes, a push never blocks. I think you've typoed "push" for "commit". Specifically: This conflicts with Mercurial terminology. *commits* never block in Mercurial. *Pushes* do, unless you use "hg push -f" (which creates an alias-less head in the target repo---its only names are the revno and the hash). I suspect what you meant to say here is that "In a modern DVCS, a commit never blocks". The reason that "commit" blocks in CVS and SVN is because in those VCSes "commit" can be considered equivalent to a Mercurial "commit + push". Ie, CVS and SVN commits can block because pushes always can block, and every commit implies a push. Proliferating new heads in the public repo is antisocial; that's what local repos are for. Unfortunately, (loosely speaking) CVS and SVN don't support local repos, so there's no way to separate commit and push for most projects. If the push blocks, the commit must do so. > This is certainly the way monotone, Mercurial, and bzr operate. If "push" wasn't a typo, please recheck your information on monotone and bzr, too. I find it hard to believe that they silently allow pushes to succeed when they would create new heads; this is a recipe for disaster. > As I said, I have not yet studied git specifically but I'm pretty > sure it works the same way. Like Mercurial, git blocks if you try to push a branch to a ref which is not a prefix of the branch you're pushing. Unlike Mercurial, "git push -f" just does what you tell it to do (push a bunch of objects and set the ref to the same commit as HEAD points to locally), and therefore will create garbage (lost commits and their dependent objects) in most cases. It does not create an implicit new head (which can have no reference except its SHA1, and thus is pretty useless). Neither behavior seems particularly useful to me. BTW, to be honest, I think "commit-before-merge" is a good advertising slogan, but it doesn't promote understanding of how dVCSes work, and only offers the GUI/CADT/IRC/XP view of their advantages. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-03 1:26 ` Stephen J. Turnbull @ 2008-01-03 2:49 ` Eric S. Raymond 0 siblings, 0 replies; 258+ messages in thread From: Eric S. Raymond @ 2008-01-03 2:49 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: acm, eliz, Richard Stallman, esr, emacs-devel Stephen J. Turnbull <stephen@xemacs.org>: > > In modern DVCSes, a push never blocks. > > I think you've typoed "push" for "commit". Specifically: You're right, I did. > BTW, to be honest, I think "commit-before-merge" is a good advertising > slogan, but it doesn't promote understanding of how dVCSes work, and > only offers the GUI/CADT/IRC/XP view of their advantages. /me becomes dizzy from a surfeit of acronyms. I coined the term mainly to contrast with the CVS/Subversion/Arch style, which requires merge before a commit can complete. I don't try to make it bear a lot of analytical weight. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 12:17 ` Eric S. Raymond 2008-01-03 1:26 ` Stephen J. Turnbull @ 2008-01-04 5:27 ` Richard Stallman 2008-01-04 5:35 ` Miles Bader 2008-01-04 12:45 ` Eric S. Raymond 1 sibling, 2 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-04 5:27 UTC (permalink / raw) To: esr; +Cc: acm, eliz, emacs-devel, esr In modern DVCSes, a push never blocks. The sequence of changesets you developed is grafted into the repo as a branch attached to the revision you pulled from. If no one else has committed or pushed against that revision, the line of development remains linear. If someone has, you have the analogue of a CVS conflict -- the revision is now a branch point with two histories going forward. Later, someone may do a merge operation that fuses those two branches together again. Thus, "commit-before-merge". I think I understand that now, but it raises other questions. Does this mean there is no concept of "trunk"? When someone who is not normally a participant in the project decides to "download the current sources", which revision does he get? More precisely, what determines which revision he gets? The operation analogous to a CVS commit to the trunk would consist of pushing a new revision and then whatever else is needed to make that revision the new trunk. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-04 5:27 ` Richard Stallman @ 2008-01-04 5:35 ` Miles Bader 2008-01-04 12:47 ` Eric S. Raymond 2008-01-05 14:30 ` Richard Stallman 2008-01-04 12:45 ` Eric S. Raymond 1 sibling, 2 replies; 258+ messages in thread From: Miles Bader @ 2008-01-04 5:35 UTC (permalink / raw) To: rms; +Cc: esr, acm, eliz, esr, emacs-devel Richard Stallman <rms@gnu.org> writes: > Does this mean there is no concept of "trunk"? When someone who is > not normally a participant in the project decides to "download the > current sources", which revision does he get? More precisely, what > determines which revision he gets? Yes there is a concept of a trunk -- at least with git, each repository can contain named branches (each a reference to the tip of some development line), and the branch called "master" is the default for many operations. -Miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-04 5:35 ` Miles Bader @ 2008-01-04 12:47 ` Eric S. Raymond 2008-01-05 14:30 ` Richard Stallman 1 sibling, 0 replies; 258+ messages in thread From: Eric S. Raymond @ 2008-01-04 12:47 UTC (permalink / raw) To: Miles Bader; +Cc: acm, eliz, rms, esr, emacs-devel Miles Bader <miles@gnu.org>: > Yes there is a concept of a trunk -- at least with git, each repository > can contain named branches (each a reference to the tip of some > development line), and the branch called "master" is the default for > many operations. Yes. I suppose you could call this treating "master" specially, which contradicts my last post in a minor way. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-04 5:35 ` Miles Bader 2008-01-04 12:47 ` Eric S. Raymond @ 2008-01-05 14:30 ` Richard Stallman 2008-01-06 1:10 ` Miles Bader 1 sibling, 1 reply; 258+ messages in thread From: Richard Stallman @ 2008-01-05 14:30 UTC (permalink / raw) To: Miles Bader; +Cc: esr, acm, eliz, esr, emacs-devel Yes there is a concept of a trunk -- at least with git, each repository can contain named branches (each a reference to the tip of some development line), and the branch called "master" is the default for many operations. So which is the operation that alters the current version in the trunk? ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 14:30 ` Richard Stallman @ 2008-01-06 1:10 ` Miles Bader 0 siblings, 0 replies; 258+ messages in thread From: Miles Bader @ 2008-01-06 1:10 UTC (permalink / raw) To: rms; +Cc: esr, acm, eliz, emacs-devel, esr Richard Stallman <rms@gnu.org> writes: > Yes there is a concept of a trunk -- at least with git, each repository > can contain named branches (each a reference to the tip of some > development line), and the branch called "master" is the default for > many operations. > > So which is the operation that alters the current version in the > trunk? For _your_ new changes: git commit For getting _others_ changes from a remote repository: git pull There are other commands that affect things, but the above are the most common. For people that use git, they really do think of "git commit" as the git analogue of "cvs commit" -- it does "most of the things" cvs commit does. I guess you can think of cvs commit as being split into two different commands in git: git commit (which does most of the work -- bundling up the changes to your working directory, adding a log message, updating the head of the current branch), and git push (which sends your local changes to a remote repository). Stephen Turnbull posted a good explanation in this thread. -Miles -- I'm beginning to think that life is just one long Yoko Ono album; no rhyme or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-04 5:27 ` Richard Stallman 2008-01-04 5:35 ` Miles Bader @ 2008-01-04 12:45 ` Eric S. Raymond 2008-01-05 14:30 ` Richard Stallman 1 sibling, 1 reply; 258+ messages in thread From: Eric S. Raymond @ 2008-01-04 12:45 UTC (permalink / raw) To: Richard Stallman; +Cc: acm, eliz, emacs-devel, esr Richard Stallman <rms@gnu.org>: > Does this mean there is no concept of "trunk"? When someone who is > not normally a participant in the project decides to "download the > current sources", which revision does he get? More precisely, what > determines which revision he gets? The "current sources" is generally going to be one of the repo tip revisions packaged into a tarball by a release manager. This is not a VCS operation. If you clone the repo, you get the entire history -- the entire DAG of revisions. Technically speaking, there is no "trunk", no distinguished branch that VCS operations treat specially. If you do an update without specifying a release or branch name, you simply get the latest sequential revision. Socially, the "trunk" is probably the branch the last release tarball was taken from. Some of these systems support named branches. When that's so, you can label a branch "trunk" if you like. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-04 12:45 ` Eric S. Raymond @ 2008-01-05 14:30 ` Richard Stallman 2008-01-05 15:29 ` Eric S. Raymond 2008-01-05 15:59 ` Andreas Schwab 0 siblings, 2 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-05 14:30 UTC (permalink / raw) To: esr; +Cc: acm, eliz, emacs-devel, esr The "current sources" is generally going to be one of the repo tip revisions packaged into a tarball by a release manager. This is not a VCS operation. That applies if/when you make a release. But what about between relesaes? Currently we recommend that people "build the source from CVS", and we don't say "from the trunk" because that is a general convention of CVS usage. If we used git, what convention would replace that? Would we have to establish our own? Would we need to maintain a file saying which branch to get and build? If so, I think the operation of adding versions to that branch would be the real analogue of a CVS commit to the urunk. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 14:30 ` Richard Stallman @ 2008-01-05 15:29 ` Eric S. Raymond 2008-01-05 15:59 ` Andreas Schwab 1 sibling, 0 replies; 258+ messages in thread From: Eric S. Raymond @ 2008-01-05 15:29 UTC (permalink / raw) To: Richard Stallman; +Cc: acm, eliz, emacs-devel, esr Richard Stallman <rms@gnu.org>: >> The "current sources" is generally going to be one of the repo tip revisions >> packaged into a tarball by a release manager. This is not a VCS operation. > > That applies if/when you make a release. But what about between relesaes? > Currently we recommend that people "build the source from CVS", and we > don't say "from the trunk" because that is a general convention of CVS > usage. > > If we used git, what convention would replace that? Would we have to > establish our own? Would we need to maintain a file saying which branch > to get and build? If so, I think the operation of adding versions > to that branch would be the real analogue of a CVS commit to the urunk. I don't know the answer to this question in the specific context of git, because I have yet not studied git workflow closely (I will soon). In Mercurial, you'd say: Build from the tip of the branch named "trunk". -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 14:30 ` Richard Stallman 2008-01-05 15:29 ` Eric S. Raymond @ 2008-01-05 15:59 ` Andreas Schwab 2008-01-06 2:14 ` Mike Mattie 1 sibling, 1 reply; 258+ messages in thread From: Andreas Schwab @ 2008-01-05 15:59 UTC (permalink / raw) To: rms; +Cc: esr, acm, eliz, esr, emacs-devel Richard Stallman <rms@gnu.org> writes: > Currently we recommend that people "build the source from CVS", and we > don't say "from the trunk" because that is a general convention of CVS > usage. > > If we used git, what convention would replace that? It's the same, basically. If you clone a git repository, your personal repository is automatically set up to track the default branch of the remote repository, which is normally the master branch. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 15:59 ` Andreas Schwab @ 2008-01-06 2:14 ` Mike Mattie 0 siblings, 0 replies; 258+ messages in thread From: Mike Mattie @ 2008-01-06 2:14 UTC (permalink / raw) To: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 6701 bytes --] On Sat, 05 Jan 2008 16:59:13 +0100 Andreas Schwab <schwab@suse.de> wrote: > Richard Stallman <rms@gnu.org> writes: > > > Currently we recommend that people "build the source from CVS", and > > we don't say "from the trunk" because that is a general convention > > of CVS usage. > > > > If we used git, what convention would replace that? > > It's the same, basically. If you clone a git repository, your > personal repository is automatically set up to track the default > branch of the remote repository, which is normally the master branch. > > Andreas. > take a look at www.kernel.org. I use git for my linux tree. I am what you would call the end-user in this case. My use is alot simpler with git. When a release is pending I check the changelogs via gitweb, do various searches for hardware and sub-systems of interest. If I like what I see I simply cut & paste the git url into a git-pull and merge the upstream changes. On a regular basis I pull from two branches, the first branch being the official linus tree, the second is usually 2.6.x.y for patch releases. Occasionally I need to debug a kernel problem with a pre-release. When this happens if the developer for the sub-system is using git I can pull fixes from his tree while we are diagnosing the problem. Once it is fixed I don't have to revert the changes before I pull from the official repo again, because the maintainer requests a pull from linus, it gets merged, and git doesn't barf on previously merged changes. In fact during this discussion I have noticed a key point that has not been mentioned. If RMS is wondering how a project is lead with a distributed system the answer is the convention of asking for a pull. I don't think anyone "pushes" changes on Linus. When they have something that is in shape for him to review they request via e-mail a pull and give the git URL. Linus is then free to look through the history of their branch. He can see not just the work, but the history. That includes all the changes, bugs, and features. By reading the history he can get a much greater sense of how it developed, not just a diff. If he likes it, he pulls it. If not they can keep at it and ask again later. When he pulls he gets the full history. CVS is crippled in that there is no way to record changes before commit. I personally do not like CVS like systems because it puts a huge burden on the developer that actually works really hard to do a clean merge for review. What I consider a clean merge for review to be is this: Broken up into changes where each change can be described succinctly by a changelog, and the change must not break compile or regress. here is a little constrast sketch: bad commit: add subsystem foo , with new data structure bar, modifying existing code baz to use new data structure bar. Good commit: 1. add new data structure bar 2. modify baz to use new data structure bar 3. add subsystem foo. Notice how in the good commit the maintainer of baz can evaluate the new data structure without wading through my new subsystem foo which he probably doesn't care about. If CVS and DVCS systems where compared to writing CVS would not have topics or paragraphs, just one huge body of text. Changes in DVCS systems can be broken up, like a body of text into paragraphs so that people can understand them better. Because CVS cannot record changes in the working copy you have to do one of two things: A. finish the entire work and publish as a single commit. This alternative is so broken you actually have to backup your working copy changes yourself. B. break the commit up into valid changes and try and maintain a diff series in the working copy until you can submit the sequence. Again backing up yourself. C. use a branch. Of course people who use CVS will say C is an entirely valid option. It does work. But it discourages casual development and definitely would discourage me. I don't like to make proposals without code to show. Often until the code is fleshed out I don't have the facts to make a proposal. With CVS I have to get a commit bit, get a branch (sounds like paperwork), and finally start hacking away. I consider this high risk because I have to declare my success (proposal + commit bit + branch) before I know if the idea will even work. I would much rather hack away on any distributed VCS where I can pick the good idea from the dozens of ideas that seemed good but did not pan out. When I would go to "request pull" or merge I can show the entire history of the development. DVCS are not perfect, but they at least make what I call a good commit possible without having to do what I consider absurd labor. When I have to work on a project using CVS or even SVN I spend a huge amount of time manually slicing and dicing diffs in diff mode. If anything goes wrong in the diff sequence I am in big trouble so I also have to keep full copies at each "change point". At that point It's not a reversion control system for me, it's just a publishing tool. All of the changes have to be maintained by hand in diff-mode. What I call good commits has two key points. It feeds changes incrementally for both review and testing. Who wants to try and test a huge chunk of code dropped in a single commit ? Doing things the right way usually pays off even in ways you don't anticipate, like git-bisect. I have personally used that to track down a problem with a IDE driver. I found the broken changeset in something like six reboots. The fix was in the Linus tree within days. I don't think it works at all to try and describe git in terms of CVS. In fact dictating how you merge by version control system is kinda supsect as well. The goal should be to turn in high quality merges, incrementally reviewed, incrementally merged and tested. Any change that breaks the compile or test-harness is sin plain and simple. If a project can't maintain that standard with their tools then their tools are a problem. If the developers are so skilled at flaking diffs from their working copy like cavemen flaking arrowheads from stone, then there is no problem. On the other hand if merging changes is a problem, then there is a *big* problem. I don't think merging is something you do for release, it's something you do to integrate the work of a team. If you can't merge you can't work together. If anything branching is for release, not development. My 2 cents at least. Please don't take any offense from any of these statements. No person or caricature was harmed in the writing of this mail. Cheers, Mike Mattie (peanut gallery) [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 9:53 ` Richard Stallman ` (2 preceding siblings ...) 2008-01-02 12:17 ` Eric S. Raymond @ 2008-01-03 1:08 ` Giorgos Keramidas 2008-01-03 2:56 ` Eric S. Raymond 2008-01-04 5:27 ` Richard Stallman 3 siblings, 2 replies; 258+ messages in thread From: Giorgos Keramidas @ 2008-01-03 1:08 UTC (permalink / raw) To: Richard Stallman; +Cc: esr, emacs-devel, esr, acm, eliz On 2008-01-02 04:53, Richard Stallman <rms@gnu.org> wrote: > You can commit a change offline (git commit). Later on, > when you are online, you say `git pull' to get the current > state of the repository, and automatical merging happens > (and the usual warnings if there are conflicts). Finally, > you say `git push' to synchronize your git repository with > the global one. > > Is this substantially different from CVS, or is it just > relabeling? It sounds like `git push' is basically equivalent > to CVS commit. Yes, there is a substantial difference between committing in a distributed SCM like Git, and Mercurial (the latter is the one I am most familiar with). A commit `attaches' a changeset to a `parent changeset', forming a changeset graph instead of a linear history. So if I pull from the central Emacs repository the changes: [1]---[2]---[3] and start committing on top of this, I will end up with a local history like this: [1]---[2]---[3]---[4]---[5]---[6] In the mean time, other people have the chance to commit their own changes to the central tree, on top of the original [3] changeset. When I finish my work, and I `pull' from the central tree again, the local Git history becomes: ,---[7]---[8] / [1]---[2]---[3]---[4]---[5]---[6] A major difference in this sort of history is that *all* changes have been safely stashed away in the local history. The working area of the repository/workspace can, for all intents and purposes, be considered volatile and completely unimporant. Having this sort of local history, I can `check out' any one of the committed changes. Looking at the `remote' changes I just pulled is possible with normal `update' commands in Mercurial (a similar command is available in Git). This means that switching between the `local' version and the `remote' version of the code is as easy as: hg update --clean 8 ; remote version is checked out hg update --clean 6 ; local version is checked out The usual commands, like `diff' also work, i.e.: hg diff -r 6:8 ; look at 6 -> 8 patch hg diff -r 8:6 ; look at the inverse patch Note that a `merge' has not happened yet. If the remote head of the history tree looks easy enough to merge, a merge operation can be done in two ways: 1) Merging of the two heads, to forma history graph like: ,---[7]---[8]---------[9] / / [1]---[2]---[3]---[4]---[5]---[6]--' 2) A `rebase' operation, which restores the linear history of the remote branch, and `rebases' all the local changesets on top of the remote branch: [1]---[2]---[3]---[7]---[8] - - - [4']---[5']---[6'] > With CVS, until you commit your changes, new changes can be > installed in the repository, and when you DO get around to > committing your changes, you will have to merge them with > whatever others have installed. Once you commit, others trying > to commit will have the burden of merging their changes with > your already-committed changes. The main ease of use from the distributed SCM systems is a result of the different from the workflow you just described. With CVS committers are encouraged to avoid committing local changes, until a future moment when ``the patch will be done and fully working''. When they reach that future point, the onus of the merging falls on the person who wants to commit. With a distributed SCM system, committing is not so `scary'. It's ok to commit often, and commit short changes. They are local. They won't break the remote tree for anyone else. Merging can also be done much more often. This means that it's ok to merge or rebase a pile of local changes 10 or 20 times, while they are being developed. If the first sort of merging described above is chosen, then repeated merges work incrementally, so conflicts that have been resolved in one of the past merges don't reappear in future merges. > With git, I would guess that the same situation obtains until > you do `git push' with your changes. Thus, I think that `git > push' is the true analogue to CVS commit. If a dSCM repository is `anointed' by the team as *the* repository, then there are hooks which can control whether: * It is ok to create `remote heads' with unmerged changes (this is what happens for example if someone pushes the sample history graph shown above, before the merge of change [9] happens) * It is ok to push new `branches' in the remote tree > This is based on surmise rather than knowledge. If it is > wrong, where is the mistake? It's mostly right. A `push' operation is that `publishes' a change in a dSCM world. The only difference is that a `commit' in a centralized SCM (like CVS) does several things, which have been split in a more fine-grained set of operations in a distributed SCM system. When a commit happens in CVS then: * A local `merge' has completed * CVS add, or remove commands have been completed * A commit sends the files to the remote server (the `publishing' part) * The local workspace state is updated to match the new state of the tree In a distributed SCM a `commit' is only part of the above: * A changeset is recorded in the local repository storage area * Local workspace state is updated A merge is not strictly necessary, and the changes haven't been published anywhere else yet. HTH, Giorgos ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-03 1:08 ` Giorgos Keramidas @ 2008-01-03 2:56 ` Eric S. Raymond 2008-01-03 3:18 ` Giorgos Keramidas 2008-01-04 5:27 ` Richard Stallman 1 sibling, 1 reply; 258+ messages in thread From: Eric S. Raymond @ 2008-01-03 2:56 UTC (permalink / raw) To: Giorgos Keramidas; +Cc: esr, Richard Stallman, emacs-devel, acm, eliz Giorgos Keramidas <keramida@ceid.upatras.gr>: > Yes, there is a substantial difference between committing in a > distributed SCM like Git, and Mercurial (the latter is the one I > am most familiar with). Note to RMS: Giorgios's explanation is better than mine. I'm just learning these systems, but he is clearly very experienced and fluent with them. Giorgios, can I interest you in being a reviewer for my survey paper? You sound like you may one of the people I need looking over my shoulder as I try to design test and benchmarking suites for DVCSes. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-03 2:56 ` Eric S. Raymond @ 2008-01-03 3:18 ` Giorgos Keramidas 0 siblings, 0 replies; 258+ messages in thread From: Giorgos Keramidas @ 2008-01-03 3:18 UTC (permalink / raw) To: Eric S. Raymond; +Cc: esr, Richard Stallman, emacs-devel, acm, eliz On 2008-01-02 21:56, "Eric S. Raymond" <esr@thyrsus.com> wrote: >Giorgos Keramidas <keramida@ceid.upatras.gr>: >> Yes, there is a substantial difference between committing in a >> distributed SCM like Git, and Mercurial (the latter is the one I >> am most familiar with). > > Note to RMS: Giorgios's explanation is better than mine. I'm > just learning these systems, but he is clearly very experienced > and fluent with them. > > Giorgios, can I interest you in being a reviewer for my survey > paper? You sound like you may one of the people I need looking over > my shoulder as I try to design test and benchmarking suites for > DVCSes. Sure. I'm not very experienced with *all* the dSCM systems, but I will gladly help with what I know about Mercurial, Git, and Bazaar (these are the ones I am acquainted with, in decreasing order of experience). I've already cloned http://thyrsus.com/hg/uvc/ because I wanted to read the article anyway. Please feel free to email me with any guidelines about the review and/or other useful things. Regards, Giorgos ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-03 1:08 ` Giorgos Keramidas 2008-01-03 2:56 ` Eric S. Raymond @ 2008-01-04 5:27 ` Richard Stallman 2008-01-04 8:51 ` David Kastrup 1 sibling, 1 reply; 258+ messages in thread From: Richard Stallman @ 2008-01-04 5:27 UTC (permalink / raw) To: Giorgos Keramidas; +Cc: esr, emacs-devel, esr, acm, eliz With CVS committers are encouraged to avoid committing local changes, until a future moment when ``the patch will be done and fully working''. When they reach that future point, the onus of the merging falls on the person who wants to commit. With a distributed SCM system, committing is not so `scary'. It's ok to commit often, and commit short changes. They are local. They won't break the remote tree for anyone else. I don't think it makes sense to compare these two different "commit" operations -- it's like comparing an apple to an orange tree branch. If you compare applies with oranges instead, the difference is much less. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-04 5:27 ` Richard Stallman @ 2008-01-04 8:51 ` David Kastrup 2008-01-05 14:30 ` Richard Stallman 0 siblings, 1 reply; 258+ messages in thread From: David Kastrup @ 2008-01-04 8:51 UTC (permalink / raw) To: rms; +Cc: esr, emacs-devel, esr, Giorgos Keramidas, acm, eliz Richard Stallman <rms@gnu.org> writes: > With CVS > committers are encouraged to avoid committing local changes, > until a future moment when ``the patch will be done and fully > working''. When they reach that future point, the onus of the > merging falls on the person who wants to commit. > > With a distributed SCM system, committing is not so `scary'. > It's ok to commit often, and commit short changes. They are > local. They won't break the remote tree for anyone else. > > I don't think it makes sense to compare these two different "commit" > operations -- it's like comparing an apple to an orange tree branch. > If you compare applies with oranges instead, the difference is > much less. I think that the comparison is quite accurate: the commit does everything that a commit in CVS does. The difference in workflow is not in committing, it is in the fact that everybody has his own repository (and all of them are equal). The difference is that cooperation works by synchronizing repositories (which does not even need a checked-out work directory), not by committing to a central repository. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-04 8:51 ` David Kastrup @ 2008-01-05 14:30 ` Richard Stallman 2008-01-05 15:28 ` David Kastrup ` (2 more replies) 0 siblings, 3 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-05 14:30 UTC (permalink / raw) To: David Kastrup; +Cc: esr, emacs-devel, esr, keramida, acm, eliz > I don't think it makes sense to compare these two different "commit" > operations -- it's like comparing an apple to an orange tree branch. > If you compare applies with oranges instead, the difference is > much less. I think that the comparison is quite accurate: the commit does everything that a commit in CVS does. The difference in workflow is not in committing, it is in the fact that everybody has his own repository (and all of them are equal). I think that is a confusing way to compare them. It focuses on similarities in implementation rather than on similarities in use and role. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 14:30 ` Richard Stallman @ 2008-01-05 15:28 ` David Kastrup 2008-01-06 10:46 ` Richard Stallman 2008-01-05 21:11 ` Stephen J. Turnbull 2008-01-07 9:35 ` Piet van Oostrum 2 siblings, 1 reply; 258+ messages in thread From: David Kastrup @ 2008-01-05 15:28 UTC (permalink / raw) To: rms; +Cc: esr, emacs-devel, esr, keramida, acm, eliz Richard Stallman <rms@gnu.org> writes: > > I don't think it makes sense to compare these two different "commit" > > operations -- it's like comparing an apple to an orange tree branch. > > If you compare applies with oranges instead, the difference is > > much less. > > I think that the comparison is quite accurate: the commit does > everything that a commit in CVS does. The difference in workflow is not > in committing, it is in the fact that everybody has his own repository > (and all of them are equal). > > I think that is a confusing way to compare them. > It focuses on similarities in implementation > rather than on similarities in use and role. But the use and role is completely the same as using a private CVS repository: all the diff and merge and branch and commit machinery works for single persons quite similar as with CVS. The difference is just that there are more elaborate mechanisms than rsync for synchronizing several private repositories. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 15:28 ` David Kastrup @ 2008-01-06 10:46 ` Richard Stallman 2008-01-06 11:10 ` David Kastrup 0 siblings, 1 reply; 258+ messages in thread From: Richard Stallman @ 2008-01-06 10:46 UTC (permalink / raw) To: David Kastrup; +Cc: esr, emacs-devel, esr, keramida, acm, eliz > I think that is a confusing way to compare them. > It focuses on similarities in implementation > rather than on similarities in use and role. But the use and role is completely the same as using a private CVS repository: all the diff and merge and branch and commit machinery works for single persons quite similar as with CVS. We are miscommunicating. I'm using the word role "role" to refer to relationship actions, such as "changing which version a user will get when he asks for the current development version". ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-06 10:46 ` Richard Stallman @ 2008-01-06 11:10 ` David Kastrup 2008-01-07 4:18 ` Richard Stallman 0 siblings, 1 reply; 258+ messages in thread From: David Kastrup @ 2008-01-06 11:10 UTC (permalink / raw) To: rms; +Cc: esr, emacs-devel, esr, keramida, acm, eliz Richard Stallman <rms@gnu.org> writes: > > I think that is a confusing way to compare them. > > It focuses on similarities in implementation > > rather than on similarities in use and role. > > But the use and role is completely the same as using a private CVS > repository: all the diff and merge and branch and commit machinery works > for single persons quite similar as with CVS. > > We are miscommunicating. I'm using the word role "role" to refer to > relationship actions, such as "changing which version a user will get > when he asks for the current development version". "the current development version" is not a concept for git. No repository is special as far as git is concerned. The "current development version" is a social, not a technical concept. For example, the git maintainer was off-line unexpectedly for some months recently. Somebody else took over seamlessly by collecting, arranging and coordinating patches on the git list into _his_ repository. When the maintainer finally came back, he more or less pulled from this person's repository (could have been one or more persons), and the "official" repo was more or less in synch. There is no single point of failure. In fact, Linux has about a dozen serious kernel repositories maintained by different persons which all have a different set of patches that they consider fit for use. They exchange patch sets, and some are accepted and some are left out, but the special role for Linus Torvalds' kernel is just that people like his criteria for what he applies and what he rejects (either ultimately, or at first). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-06 11:10 ` David Kastrup @ 2008-01-07 4:18 ` Richard Stallman 2008-01-07 4:36 ` dhruva ` (3 more replies) 0 siblings, 4 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-07 4:18 UTC (permalink / raw) To: David Kastrup; +Cc: esr, emacs-devel, esr, keramida, acm, eliz "the current development version" is not a concept for git. No repository is special as far as git is concerned. The "current development version" is a social, not a technical concept. For example, the git maintainer was off-line unexpectedly for some months recently. Somebody else took over seamlessly by collecting, arranging and coordinating patches on the git list into _his_ repository. With CVS, people can get the current version of every program on savannah in a uniform way. What you say seems to imply that that is not possible with git. That seems like a big step backwards. Within a community of people that work together, it won't be a problem. They will know to look THERE instead of HERE. But users in general can't be expected to check for that sort of thing before they get the current development Emacs. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 4:18 ` Richard Stallman @ 2008-01-07 4:36 ` dhruva 2008-01-07 4:52 ` Sam Steingold ` (2 subsequent siblings) 3 siblings, 0 replies; 258+ messages in thread From: dhruva @ 2008-01-07 4:36 UTC (permalink / raw) To: rms; +Cc: esr, emacs-devel, esr, keramida, acm, eliz Hello, On Jan 7, 2008 9:48 AM, Richard Stallman <rms@gnu.org> wrote: > With CVS, people can get the current version of every program on > savannah in a uniform way. What you say seems to imply that that is > not possible with git. That seems like a big step backwards. There can still be one _offcial_ repository from which "people" (non core developer community) can pull from. This could be equivalent to the current HEAD. The only difference would be that in CVS, every core developer checks into the _official_ repository where as in a dVCS, the maintainer can pull in the changes from the various core developers (or core developers can push) into it. > Within a community of people that work together, it won't be a > problem. They will know to look THERE instead of HERE. But users in > general can't be expected to check for that sort of thing before they > get the current development Emacs. The above work flow would allow a single point access to the latest as it is in the current state with CVS. You could treat all other dVCS repositories belonging to various developers and different features as current branches in CVS. As the users know of HEAD in CVS, IMO, they will easily (I presume) learn about "master" in GIT or "default" in mercurial. with best regards, dhruva -- Contents reflect my personal views only! ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 4:18 ` Richard Stallman 2008-01-07 4:36 ` dhruva @ 2008-01-07 4:52 ` Sam Steingold 2008-01-07 5:09 ` dhruva ` (2 more replies) 2008-01-07 5:16 ` Jason Earl 2008-01-07 8:15 ` David Kastrup 3 siblings, 3 replies; 258+ messages in thread From: Sam Steingold @ 2008-01-07 4:52 UTC (permalink / raw) To: emacs-devel > * Richard Stallman <ezf@tah.bet> [2008-01-06 23:18:05 -0500]: > > "the current development version" is not a concept for git. No > repository is special as far as git is concerned. The "current > development version" is a social, not a technical concept. For example, > the git maintainer was off-line unexpectedly for some months recently. > Somebody else took over seamlessly by collecting, arranging and > coordinating patches on the git list into _his_ repository. > > With CVS, people can get the current version of every program on > savannah in a uniform way. What you say seems to imply that that is > not possible with git. That seems like a big step backwards. No, this just means that if savannah goes down, nobody can get emacs from CVS (people can't work on emacs, can't exchange patches &c). with DVCS, someone can announce that he is stepping in for savannah and people would hardly notice other than by having to give a different argument to "git pull" and "git push". Note however that with CVS, getting CVS head and building it is hardly more expensive than downloading a source tarball - wrt both bandwidth and disk space. With git, the situation is vastly different: you cannot just get the head, you always get the whole change history, so instead of 40MB, you will be getting and storing 200MB. This may not be a big deal these days for many people, but it might be a showstopper for some. -- Sam Steingold (http://sds.podval.org/) on Fedora release 8 (Werewolf) http://mideasttruth.com http://memri.org http://israelunderattack.slide.com http://palestinefacts.org http://truepeace.org http://ffii.org Isn't "Microsoft Works" an advertisement lie? ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 4:52 ` Sam Steingold @ 2008-01-07 5:09 ` dhruva 2008-01-07 8:17 ` David Kastrup 2008-01-07 15:40 ` CHENG Gao 2 siblings, 0 replies; 258+ messages in thread From: dhruva @ 2008-01-07 5:09 UTC (permalink / raw) To: sds, emacs-devel Hi, On Jan 7, 2008 10:22 AM, Sam Steingold <sds@gnu.org> wrote: > Note however that with CVS, getting CVS head and building it is hardly > more expensive than downloading a source tarball - wrt both bandwidth > and disk space. With git, the situation is vastly different: you cannot > just get the head, you always get the whole change history, so instead > of 40MB, you will be getting and storing 200MB. This may not be a big > deal these days for many people, but it might be a showstopper for some. FWIK, there are options to specify the depth of revision history you want in a clone. You can reduce the data size. The GIT/Mercurial repository frontend has an option to make a snapshot of the current repository. People could use that feature too. IMHO, it is something that is realizable with dVCS. -dky -- Contents reflect my personal views only! ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 4:52 ` Sam Steingold 2008-01-07 5:09 ` dhruva @ 2008-01-07 8:17 ` David Kastrup 2008-01-07 15:37 ` Stefan Monnier 2008-01-07 15:40 ` CHENG Gao 2 siblings, 1 reply; 258+ messages in thread From: David Kastrup @ 2008-01-07 8:17 UTC (permalink / raw) To: emacs-devel Sam Steingold <sds@gnu.org> writes: >> * Richard Stallman <ezf@tah.bet> [2008-01-06 23:18:05 -0500]: >> >> "the current development version" is not a concept for git. No >> repository is special as far as git is concerned. The "current >> development version" is a social, not a technical concept. For example, >> the git maintainer was off-line unexpectedly for some months recently. >> Somebody else took over seamlessly by collecting, arranging and >> coordinating patches on the git list into _his_ repository. >> >> With CVS, people can get the current version of every program on >> savannah in a uniform way. What you say seems to imply that that is >> not possible with git. That seems like a big step backwards. > > No, this just means that if savannah goes down, nobody can get emacs > from CVS (people can't work on emacs, can't exchange patches &c). > with DVCS, someone can announce that he is stepping in for savannah and > people would hardly notice other than by having to give a different > argument to "git pull" and "git push". > > Note however that with CVS, getting CVS head and building it is hardly > more expensive than downloading a source tarball - wrt both bandwidth > and disk space. With git, the situation is vastly different: you cannot > just get the head, you always get the whole change history, so instead > of 40MB, you will be getting and storing 200MB. This may not be a big > deal these days for many people, but it might be a showstopper for some. You just need to get the history once. After that, only deltas are transmitted. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 8:17 ` David Kastrup @ 2008-01-07 15:37 ` Stefan Monnier 2008-01-07 15:47 ` David Kastrup 0 siblings, 1 reply; 258+ messages in thread From: Stefan Monnier @ 2008-01-07 15:37 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel > You just need to get the history once. After that, only deltas are > transmitted. Until you need to checkout a new copy of the trunk, of course. Also, many DVCS keep a copy of the repository per checked out tree, which becomes costly when you have many checked out trees (e.g. unicode, multi-tty, trunk, your-own, 22, lexbind, yournameit, plus some copies for tentative hacks, ...). Stefan ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 15:37 ` Stefan Monnier @ 2008-01-07 15:47 ` David Kastrup 2008-01-07 16:22 ` Stefan Monnier 0 siblings, 1 reply; 258+ messages in thread From: David Kastrup @ 2008-01-07 15:47 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> You just need to get the history once. After that, only deltas are >> transmitted. > > Until you need to checkout a new copy of the trunk, of course. Huh? Why would you need to do that? Anyway, even if you think you need another checked out work copy (and with git I am very rarely in that situation), you can either clone your original repository (optionally using hard links to its object store to save space) or at least tell git to reuse its object store. > Also, many DVCS keep a copy of the repository per checked out tree, > which becomes costly when you have many checked out trees > (e.g. unicode, multi-tty, trunk, your-own, 22, lexbind, yournameit, > plus some copies for tentative hacks, ...). I don't see why you would need more than one tree to work with at any given point of time. And even then, you can tell git to share all the respective data. Either using a single repository (probably the sanest variant with regard to pulling and updates) or multiple ones. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 15:47 ` David Kastrup @ 2008-01-07 16:22 ` Stefan Monnier 2008-01-07 17:09 ` David Kastrup 0 siblings, 1 reply; 258+ messages in thread From: Stefan Monnier @ 2008-01-07 16:22 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel > I don't see why you would need more than one tree to work with at any > given point of time. I often work for example with 4 branches: the 22 branch, the trunk, the unicode branch, and my own branch with its local hacks. I switch between them often enough that using a single tree and switching within the tree would be a real pain in the *** because of the need to rebuild all the .o and .elc files after each switch. Stefan ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 16:22 ` Stefan Monnier @ 2008-01-07 17:09 ` David Kastrup 0 siblings, 0 replies; 258+ messages in thread From: David Kastrup @ 2008-01-07 17:09 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> I don't see why you would need more than one tree to work with at any >> given point of time. > > I often work for example with 4 branches: the 22 branch, the trunk, the > unicode branch, and my own branch with its local hacks. I switch > between them often enough that using a single tree and switching within > the tree would be a real pain in the *** because of the need to rebuild > all the .o and .elc files after each switch. Hm? Why do you build Emacs in-place, then? I understand the need for 4 build directories, but do you really need 4 source directories? And even 4 repositories? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 4:52 ` Sam Steingold 2008-01-07 5:09 ` dhruva 2008-01-07 8:17 ` David Kastrup @ 2008-01-07 15:40 ` CHENG Gao 2008-01-07 23:36 ` Stephen J. Turnbull 2008-01-08 2:56 ` Mike Mattie 2 siblings, 2 replies; 258+ messages in thread From: CHENG Gao @ 2008-01-07 15:40 UTC (permalink / raw) To: emacs-devel *On Sun, 06 Jan 2008 23:52:53 -0500 * Also sprach Sam Steingold <sds@gnu.org>: > Note however that with CVS, getting CVS head and building it is hardly > more expensive than downloading a source tarball - wrt both bandwidth > and disk space. With git, the situation is vastly different: you cannot > just get the head, you always get the whole change history, so instead > of 40MB, you will be getting and storing 200MB. This may not be a big > deal these days for many people, but it might be a showstopper for some. Yes you are right. Ever I tried to git clone emacs git repo at home, and it took forever so I had to abort the mission. I got a 2m ADSL at home. Instead I git cloned it in office, and it took only several minutes with 10M line. My experience and worry is git clone may be slow for slow connections. Personally I hope Emacs can be developped with DVCS like git or Mercurial or bzr since I trust it's easier for Emacs developers to add new features and for users to test these features. And then developers can submit mature features/codes to some dedicated mailing list via email (git or hg or bzr all have this feature to easily generate and send patchs) for review by core developer(s) or a dedicated team. If codes are accepted, they can be merged into OFFICIAL CENTRALIZED Emacs repo, and at the same time propogated to Emacs CVS. (If I understand correctly, it's what Bug Buddy of BZR does). I hope Emacs can use this decentralized/centralized combination. It makes development easier and codes can get more extensive testing since users can test features by cloning some unofficial work-in-progress features. And at the same time, it can maintain stability and integrity of official repo. I think the proper time is after merge of unicode-2 branch since then only two or three branches need be kept - master, emacs_22_base (& lexbind?). -- Volo, non valeo ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 15:40 ` CHENG Gao @ 2008-01-07 23:36 ` Stephen J. Turnbull 2008-01-08 4:31 ` CHENG Gao 2008-01-08 5:07 ` Mike Mattie 2008-01-08 2:56 ` Mike Mattie 1 sibling, 2 replies; 258+ messages in thread From: Stephen J. Turnbull @ 2008-01-07 23:36 UTC (permalink / raw) To: CHENG Gao; +Cc: emacs-devel CHENG Gao writes: > Yes you are right. Ever I tried to git clone emacs git repo at home, and > it took forever so I had to abort the mission. I got a 2m ADSL at home. > Instead I git cloned it in office, and it took only several minutes with > 10M line. My experience and worry is git clone may be slow for slow > connections. There are workarounds for this. For example, find a volunteer, send them a SASE and a blank CD-ROM and request a copy of the .git directory. This costs only a few minutes of your time and a few dollars in S&H. Or maybe the FSF could make a few bucks with a service like this. It might also be faster to rsync the .git directory, although if the .git directory is well-packed it shouldn't make much difference. As you suggest, a CVS mirror of the official public repo could be maintained as a convenience to nondevelopers. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 23:36 ` Stephen J. Turnbull @ 2008-01-08 4:31 ` CHENG Gao 2008-01-08 5:07 ` Mike Mattie 1 sibling, 0 replies; 258+ messages in thread From: CHENG Gao @ 2008-01-08 4:31 UTC (permalink / raw) To: emacs-devel *On Tue, 08 Jan 2008 08:36:54 +0900 * Also sprach "Stephen J. Turnbull" <stephen@xemacs.org>: > There are workarounds for this. For example, find a volunteer, send > them a SASE and a blank CD-ROM and request a copy of the .git > directory. This costs only a few minutes of your time and a few > dollars in S&H. Or maybe the FSF could make a few bucks with a service > like this. > > It might also be faster to rsync the .git directory, although if the > .git directory is well-packed it shouldn't make much difference. > > As you suggest, a CVS mirror of the official public repo could be > maintained as a convenience to nondevelopers. In fact it's not problem for me. I git cloned it in office and copied it home. Slowness is in "Indexing objects" stage since Emacs has huge number of objects (more than 450000 now). -- The enemies of Freedom do not argue; they shout and they shoot. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 23:36 ` Stephen J. Turnbull 2008-01-08 4:31 ` CHENG Gao @ 2008-01-08 5:07 ` Mike Mattie 1 sibling, 0 replies; 258+ messages in thread From: Mike Mattie @ 2008-01-08 5:07 UTC (permalink / raw) To: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 1240 bytes --] On Tue, 08 Jan 2008 08:36:54 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: > CHENG Gao writes: > > > Yes you are right. Ever I tried to git clone emacs git repo at > > home, and it took forever so I had to abort the mission. I got a > > 2m ADSL at home. Instead I git cloned it in office, and it took > > only several minutes with 10M line. My experience and worry is git > > clone may be slow for slow connections. > > There are workarounds for this. For example, find a volunteer, send > them a SASE and a blank CD-ROM and request a copy of the .git > directory. This costs only a few minutes of your time and a few > dollars in S&H. Or maybe the FSF could make a few bucks with a > service like this. > > It might also be faster to rsync the .git directory, although if the > .git directory is well-packed it shouldn't make much difference. > > As you suggest, a CVS mirror of the official public repo could be > maintained as a convenience to nondevelopers. non-developers quickly turn into developers once they hit a bug. > > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-devel [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 15:40 ` CHENG Gao 2008-01-07 23:36 ` Stephen J. Turnbull @ 2008-01-08 2:56 ` Mike Mattie 2008-01-08 9:37 ` Andreas Schwab 1 sibling, 1 reply; 258+ messages in thread From: Mike Mattie @ 2008-01-08 2:56 UTC (permalink / raw) To: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 1769 bytes --] On Mon, 07 Jan 2008 23:40:51 +0800 CHENG Gao <chenggao@gmail.com> wrote: > *On Sun, 06 Jan 2008 23:52:53 -0500 > * Also sprach Sam Steingold <sds@gnu.org>: > > > Note however that with CVS, getting CVS head and building it is > > hardly more expensive than downloading a source tarball - wrt both > > bandwidth and disk space. With git, the situation is vastly > > different: you cannot just get the head, you always get the whole > > change history, so instead of 40MB, you will be getting and storing > > 200MB. This may not be a big deal these days for many people, but > > it might be a showstopper for some. > > Yes you are right. Ever I tried to git clone emacs git repo at home, > and it took forever so I had to abort the mission. I got a 2m ADSL at > home. Instead I git cloned it in office, and it took only several > minutes with 10M line. My experience and worry is git clone may be > slow for slow connections. good point, even in the U.S the midwest is still on dialup outside of the major metro regions. I am on broad-band so I never checked if git has a "resume" option to continue a clone operation that is interrupted, or if that is integral to clone. The second, third world is also a consideration e.g The current architect of the parrot project lives somewhere in Africa. There is alot of talent outside of the regions that are blinding on a connectivity map. Another thing that has not been mentioned is the usefulness of dropping or limiting history. I made a slight mistake in the arguments to git log and I ended up with a 23 Mb log buffer that went back to the 'mid 90's. Some potential pitfalls to consider. I don't think they are show-stoppers but they are scenarios that need consideration. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-08 2:56 ` Mike Mattie @ 2008-01-08 9:37 ` Andreas Schwab 0 siblings, 0 replies; 258+ messages in thread From: Andreas Schwab @ 2008-01-08 9:37 UTC (permalink / raw) To: Mike Mattie; +Cc: emacs-devel Mike Mattie <codermattie@gmail.com> writes: > good point, even in the U.S the midwest is still on dialup outside of > the major metro regions. I am on broad-band so I never checked if git > has a "resume" option to continue a clone operation that is interrupted, > or if that is integral to clone. You can clone a shallow copy of the repository and deepen it later. > Another thing that has not been mentioned is the usefulness of dropping > or limiting history. I made a slight mistake in the arguments to git > log and I ended up with a 23 Mb log buffer that went back to the 'mid 90's. You can always interrupt the process. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 4:18 ` Richard Stallman 2008-01-07 4:36 ` dhruva 2008-01-07 4:52 ` Sam Steingold @ 2008-01-07 5:16 ` Jason Earl 2008-01-07 17:16 ` Richard Stallman 2008-01-07 8:15 ` David Kastrup 3 siblings, 1 reply; 258+ messages in thread From: Jason Earl @ 2008-01-07 5:16 UTC (permalink / raw) To: rms; +Cc: esr, emacs-devel, esr, keramida, acm, eliz Richard Stallman <rms@gnu.org> writes: > "the current development version" is not a concept for git. No > repository is special as far as git is concerned. The "current > development version" is a social, not a technical concept. For example, > the git maintainer was off-line unexpectedly for some months recently. > Somebody else took over seamlessly by collecting, arranging and > coordinating patches on the git list into _his_ repository. > > With CVS, people can get the current version of every program on > savannah in a uniform way. What you say seems to imply that that is > not possible with git. That seems like a big step backwards. A distributed VCS can be used just like CVS. The fans of distributed VCS systems like to talk about the many benefits of a distributed system, but I don't know of a single major project that uses a dVCS that doesn't have a canonical URL. For example, if you wanted to start hacking on git (assuming you had a copy of git installed already) you could do: git clone git://git.kernel.org/pub/scm/git/git.git/ If you wanted to hack on mercurial and you had a mercurial client installed you would use this command: hg clone http://selenic.com/hg/ All of the improvements to git (or mercurial) that are likely to become part of a release eventually end up in the default branch in much the same way that all of the improvements that are likely to end up in a release of emacs get put into CVS. The difference is that dVCSes like git allow for a much more flexible workflow (especially for people that spend a lot of time disconnected). > Within a community of people that work together, it won't be a > problem. They will know to look THERE instead of HERE. But users > in general can't be expected to check for that sort of thing before > they get the current development Emacs. Folks that like distributed version control systems (and that includes basically everyone that has tried one) like to point out that if something happened to the canonical URL work could continue on without it until things were sorted out. That doesn't mean, however, that you have to do without the canonical URL. It simply means that you *could* do without the canonical URL in a pinch. If CVS is down, you are finished until things get sorted out. With a distributed system the failure of one branch isn't more than a minor annoyance. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 5:16 ` Jason Earl @ 2008-01-07 17:16 ` Richard Stallman 2008-01-07 17:45 ` Gregory Collins 2008-01-07 21:28 ` Jason Earl 0 siblings, 2 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-07 17:16 UTC (permalink / raw) To: Jason Earl; +Cc: esr, emacs-devel, esr, keramida, acm, eliz A distributed VCS can be used just like CVS. The fans of distributed VCS systems like to talk about the many benefits of a distributed system, but I don't know of a single major project that uses a dVCS that doesn't have a canonical URL. For example, if you wanted to start hacking on git (assuming you had a copy of git installed already) you could do: git clone git://git.kernel.org/pub/scm/git/git.git/ That is good. Can you explain what that URL means? Does the URL identify a specific revision? Or does the URL identify a repository? If it identifies a repository, how does git decide which revision to get? ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 17:16 ` Richard Stallman @ 2008-01-07 17:45 ` Gregory Collins 2008-01-08 19:07 ` Richard Stallman 2008-01-07 21:28 ` Jason Earl 1 sibling, 1 reply; 258+ messages in thread From: Gregory Collins @ 2008-01-07 17:45 UTC (permalink / raw) To: rms; +Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > Can you explain what that URL means? Does the URL identify a specific > revision? Or does the URL identify a repository? If it identifies a > repository, how does git decide which revision to get? The URL identifies the repository. When you do a "pull", you obtain the _set_ of all revisions that exist on the remote but don't exist in your local tree (remember that in a distributed context every repository has a complete history). You can then fast-forward the state of your working directory to any of those revisions (similar to "cvs update -r {foo}" but without a server trip). This local update is astonishingly faster than a network update; git in particular can update an entire source tree to a different revision id so quickly that new users often wonder "did it just core dump?" G. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 17:45 ` Gregory Collins @ 2008-01-08 19:07 ` Richard Stallman 2008-01-08 19:50 ` Miles Bader 2008-01-13 20:06 ` Giorgos Keramidas 0 siblings, 2 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-08 19:07 UTC (permalink / raw) To: Gregory Collins; +Cc: emacs-devel The URL identifies the repository. When you do a "pull", you obtain the _set_ of all revisions that exist on the remote but don't exist in your local tree (remember that in a distributed context every repository has a complete history). What command do you use to get "the current development version" sources out of that local copy of the repository? ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-08 19:07 ` Richard Stallman @ 2008-01-08 19:50 ` Miles Bader 2008-01-13 20:06 ` Giorgos Keramidas 1 sibling, 0 replies; 258+ messages in thread From: Miles Bader @ 2008-01-08 19:50 UTC (permalink / raw) To: rms; +Cc: Gregory Collins, emacs-devel Richard Stallman <rms@gnu.org> writes: > The URL identifies the repository. When you do a "pull", you obtain the > _set_ of all revisions that exist on the remote but don't exist in your > local tree (remember that in a distributed context every repository has > a complete history). > > What command do you use to get "the current development version" > sources out of that local copy of the repository? [The following is about git] When you originally create a working directory + local-repository (the "local repository" is in the WD's ".git" subdirectory), you use the "clone" command: git clone git://git.sv.gnu.org/emacs.git The resulting working directory will contain "the current development version"; in git that is called "master" branch. You can subsequently use the "git pull" command to update that, getting any changes from the remote repository: cd emacs git pull Technically, what is happening when you give "git pull" above is that it: (1) Fetches updates to the "remote master branch" (2) Merges those updates into the "local master branch"; this merge is usually trivial but if there are conflicts, may require the user to resolve them. The working directory will be updated in the process. Giving "git push" essentially does the opposite -- transfers any updates to the "local master branch" to the remote master branch. "git commit" commits your W.D. changes to the "local master branch", -Miles -- "Suppose we've chosen the wrong god. Every time we go to church we're just making him madder and madder." -- Homer Simpson ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-08 19:07 ` Richard Stallman 2008-01-08 19:50 ` Miles Bader @ 2008-01-13 20:06 ` Giorgos Keramidas 2008-01-14 11:28 ` Richard Stallman 1 sibling, 1 reply; 258+ messages in thread From: Giorgos Keramidas @ 2008-01-13 20:06 UTC (permalink / raw) To: Richard Stallman; +Cc: Gregory Collins, emacs-devel On 2008-01-08 14:07, Richard Stallman <rms@gnu.org> wrote: > The URL identifies the repository. When you do a "pull", you obtain the > _set_ of all revisions that exist on the remote but don't exist in your > local tree (remember that in a distributed context every repository has > a complete history). > > What command do you use to get "the current development version" > sources out of that local copy of the repository? The current development version is identified by either a specific URL (i.e. the unique location of an online repository st savannah) or by a specific branch in this repository. That is, the main "development version" of project $FOO may be: http://hg.savannah.gnu.org/sources/emacs/trunk or the 'main' branch in this repository. Given a local 'clone' of this branch, say in ~/work/emacs/trunk a user can get the latest development version with: cd ~/work/emacs/trunk hg pull --update ; or 'hg pull -u' This will perform both steps of (a) grabbing any changes of the remote tree that we don't have and stashing them in the local repository storage area, and (b) check out the latest version of the sources. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-13 20:06 ` Giorgos Keramidas @ 2008-01-14 11:28 ` Richard Stallman 0 siblings, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-14 11:28 UTC (permalink / raw) To: Giorgos Keramidas; +Cc: greg, emacs-devel That is, the main "development version" of project $FOO may be: http://hg.savannah.gnu.org/sources/emacs/trunk or the 'main' branch in this repository. Given a local 'clone' of this branch, say in ~/work/emacs/trunk a user can get the latest development version with: cd ~/work/emacs/trunk hg pull --update ; or 'hg pull -u' This will perform both steps of (a) grabbing any changes of the remote tree that we don't have and stashing them in the local repository storage area, and (b) check out the latest version of the sources. If I do a local commit, does that change the "latest version" in my local repository? If I do a pull from my local repository to the main one, does that change the "latest version" in the shared repository? ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 17:16 ` Richard Stallman 2008-01-07 17:45 ` Gregory Collins @ 2008-01-07 21:28 ` Jason Earl 1 sibling, 0 replies; 258+ messages in thread From: Jason Earl @ 2008-01-07 21:28 UTC (permalink / raw) To: rms; +Cc: esr, emacs-devel, esr, keramida, acm, eliz Richard Stallman <rms@gnu.org> writes: > A distributed VCS can be used just like CVS. The fans of > distributed VCS systems like to talk about the many benefits of > a distributed system, but I don't know of a single major project > that uses a dVCS that doesn't have a canonical URL. For > example, if you wanted to start hacking on git (assuming you had > a copy of git installed already) you could do: > > git clone git://git.kernel.org/pub/scm/git/git.git/ > > That is good. > > Can you explain what that URL means? Does the URL identify a > specific revision? Or does the URL identify a repository? If it > identifies a repository, how does git decide which revision to get? The above command would create a copy of the entire git master repository on your machine. It holds all of the revisions that have ever been pushed to that particular repository. However, by default it does the right thing and checks out the tip of the master branch from that repository. In other words, it is no more difficult to follow the main trunk of the canonical repository with git than it is with CVS. The primary difference is that with a dVCS you can do quite a few tricks that you can't do with CVS. Jason ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 4:18 ` Richard Stallman ` (2 preceding siblings ...) 2008-01-07 5:16 ` Jason Earl @ 2008-01-07 8:15 ` David Kastrup 2008-01-07 8:33 ` Giorgos Keramidas 3 siblings, 1 reply; 258+ messages in thread From: David Kastrup @ 2008-01-07 8:15 UTC (permalink / raw) To: rms; +Cc: esr, emacs-devel, esr, keramida, acm, eliz Richard Stallman <rms@gnu.org> writes: > "the current development version" is not a concept for git. No > repository is special as far as git is concerned. The "current > development version" is a social, not a technical concept. For example, > the git maintainer was off-line unexpectedly for some months recently. > Somebody else took over seamlessly by collecting, arranging and > coordinating patches on the git list into _his_ repository. > > With CVS, people can get the current version of every program on > savannah in a uniform way. What you say seems to imply that that is > not possible with git. That seems like a big step backwards. Huh? Declare a repository as official, and people can sync to it and "get the current version of every program on Savannah in a uniform way". They can sync to any other repository (or pull changes on top of other already pulled changes), too, without disturbing their setup. But it is not like they would magically get something they didn't ask for, or would not always be able to tell what changes in addition to the Savannah remote state they had applied in their own repository. > Within a community of people that work together, it won't be a > problem. They will know to look THERE instead of HERE. But users in > general can't be expected to check for that sort of thing before they > get the current development Emacs. Huh? I can get an rsync of Emacs CVS, check something into that copy and publish it on a server. Same thing. A user can't usefully work with two CVS repositories at once, sure, but the THERE/HERE confusion is just the same. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 8:15 ` David Kastrup @ 2008-01-07 8:33 ` Giorgos Keramidas 2008-01-07 23:50 ` Stephen J. Turnbull 0 siblings, 1 reply; 258+ messages in thread From: Giorgos Keramidas @ 2008-01-07 8:33 UTC (permalink / raw) To: David Kastrup; +Cc: esr, rms, emacs-devel, esr, acm, eliz On 2008-01-07 09:15, David Kastrup <dak@gnu.org> wrote: >Richard Stallman <rms@gnu.org> writes: >> "the current development version" is not a concept for git. No >> repository is special as far as git is concerned. The "current >> development version" is a social, not a technical concept. For example, >> the git maintainer was off-line unexpectedly for some months recently. >> Somebody else took over seamlessly by collecting, arranging and >> coordinating patches on the git list into _his_ repository. >> >> With CVS, people can get the current version of every program on >> savannah in a uniform way. What you say seems to imply that that is >> not possible with git. That seems like a big step backwards. > > Huh? Declare a repository as official, and people can sync to it and > "get the current version of every program on Savannah in a uniform way". > They can sync to any other repository (or pull changes on top of other > already pulled changes), too, without disturbing their setup. But it is > not like they would magically get something they didn't ask for, or > would not always be able to tell what changes in addition to the > Savannah remote state they had applied in their own repository. I think there's a misunderstanding, but it's ok. Richard, the main `new feature' of a DVCS is not that it changes anything about the `central' repository. It would still be possible to name a well defined, well known place where the official Emacs source tree lives. Since savannah is a well known place for Emacs, that's where the official tree should be, of course. >> Within a community of people that work together, it won't be a >> problem. They will know to look THERE instead of HERE. But users in >> general can't be expected to check for that sort of thing before they >> get the current development Emacs. > > Huh? I can get an rsync of Emacs CVS, check something into that copy > and publish it on a server. Same thing. A user can't usefully work > with two CVS repositories at once, sure, but the THERE/HERE confusion is > just the same. ... and this scratches the surface of the `new feature' of a DVCS. There is still a `central' repository, which is well known and used for the official releases. But developers can *also* collaborate with each other by directly exchanging changesets with each other. They don't have to specificlly go through a single CVS tree to do this. They still *can* go through the `central' repository for all their work, it's just not mandatory. - Giorgos ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-07 8:33 ` Giorgos Keramidas @ 2008-01-07 23:50 ` Stephen J. Turnbull 0 siblings, 0 replies; 258+ messages in thread From: Stephen J. Turnbull @ 2008-01-07 23:50 UTC (permalink / raw) To: Giorgos Keramidas; +Cc: esr, rms, emacs-devel, esr, acm, eliz Giorgos Keramidas writes: > ... and this scratches the surface of the `new feature' of a DVCS. > There is still a `central' repository, which is well known and used for > the official releases. Technically, this is not true. I know of several projects (the late great Arch project, for one; SXEmacs, for another), where essentially no pair of users who were building from source were working with the same tree, let alone the same repository. Official releases came from the repository of whoever was the release manager du jour. They were defined by globally-valid "tags", not by repository. The central repository is a social construct in a dVCS. And the trunk is a social construct in a dVCS. However, for most projects, including Emacs, both social constructs will emerge naturally, even automatically. It is not something the core Emacs stakeholders should worry about; in Emacs, it will take care of itself. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 14:30 ` Richard Stallman 2008-01-05 15:28 ` David Kastrup @ 2008-01-05 21:11 ` Stephen J. Turnbull 2008-01-06 18:08 ` Richard Stallman 2008-01-07 9:35 ` Piet van Oostrum 2 siblings, 1 reply; 258+ messages in thread From: Stephen J. Turnbull @ 2008-01-05 21:11 UTC (permalink / raw) To: rms; +Cc: emacs-devel, esr, keramida, acm, eliz Richard Stallman writes: > I think that is a confusing way to compare them. > It focuses on similarities in implementation > rather than on similarities in use and role. Exactly. Let's try the use and role explanation. Usage summary: cvs commit ~ git commit ; git push cvs update ~ git pull Discussion: In CVS, there normally is no local repository, and even if there were one, CVS provides no mechanism for communication between the local repository and the "official" one. So to record your changes as a new version *and* publish your changes, you simply commit: you workspace --- cvs commit --> public repo on server To get others' changes, you pull: you workspace <-- cvs update --- public repo on server In git (and all the others under discussion), to record your changes as a new version, you commit, and then to publish your changes, you push: you you workspace --- git commit --> private repo --- git push --> public repo on laptop on server To get other's changes, you pull: you workspace <-- private repo <-- git pull --- public repo on laptop on server Note that the update of the local workspace is implicit (automatically done by "git pull"). For you personally, frequently disconnected but (I assume) carrying a laptop, that's all you *need* to know, and that's all you'll see of what's happening. The omission of discussion of which branch or trunk etc is deliberate and correct. All VCSes have a notion of the "default branch". All you *need* to know is that the "default branch" of the "official repository is the "trunk", and that the "usual way" of setting up a local clone results in CVS-like behavior, except that to update the trunk, you must first commit locally, then push to the official repository. This separation of commit from push is a huge advantage to those who are often disconnected. I should also mention that some dVCSes *require* that you explicitly select the commits you wish to make. For example, if you want git to behave recursively the way "cvs commit" does, you need to say "git commit -a". However, the analog of "cvs commit file1 file2 ..." is "git commit file1 file2 ...", so I would guess you won't find it hard to acquire the habits. There are many other advantages to these tools, but you can acquire those skills at need. You'll also *want* a deeper understanding of the various operations before making a decision, I'm sure. My purpose here is merely to show how to map your current workflow into the workflow you'd need to use with a dVCS to accomplish the same tasks. Note that others can be doing all the wild-sounding things like "local branching", "pulling from private repos", "cherrypicking", and "rebasing", but you don't need to notice until it suits your purpose. Finally, you probably already know this, but I should caution the reader that words like "commit" and "push" alone do not necessarily have the same meaning as "$VCS commit" and "$VCS push" do. In fact, the various VCSes differ quite a bit in usage, and often end up with a set of commands implementing the same semantics but with the command names permuted! But those are fine points. The basic roles of the commands (at the eagle's eye view given above) remain intuitively similar. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 21:11 ` Stephen J. Turnbull @ 2008-01-06 18:08 ` Richard Stallman 0 siblings, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-06 18:08 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel, esr, keramida, acm, eliz There are many other advantages to these tools, but you can acquire those skills at need. You'll also *want* a deeper understanding of the various operations before making a decision, I'm sure. My purpose here is merely to show how to map your current workflow into the workflow you'd need to use with a dVCS to accomplish the same tasks. Thank you. I'm willing in principle to switch to a DVCS, depending on details. I don't want to study them all myself, since I am busy. And if a new team of maintainers takes over, they may as well choose the VCS, as long as I CAN use it. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-05 14:30 ` Richard Stallman 2008-01-05 15:28 ` David Kastrup 2008-01-05 21:11 ` Stephen J. Turnbull @ 2008-01-07 9:35 ` Piet van Oostrum 2 siblings, 0 replies; 258+ messages in thread From: Piet van Oostrum @ 2008-01-07 9:35 UTC (permalink / raw) To: emacs-devel >>>>> Richard Stallman <rms@gnu.org> (RS) wrote: >>> I don't think it makes sense to compare these two different "commit" >>> operations -- it's like comparing an apple to an orange tree branch. >>> If you compare applies with oranges instead, the difference is >>> much less. >RS> I think that the comparison is quite accurate: the commit does >RS> everything that a commit in CVS does. The difference in workflow >RS> is not in committing, it is in the fact that everybody has his own >RS> repository (and all of them are equal). >RS> I think that is a confusing way to compare them. >RS> It focuses on similarities in implementation >RS> rather than on similarities in use and role. In both cases committing means that you make a permanent record of the state of your workspace in the repository. The difference is that in CVS there is a central repository whereas in a DVC system each user has its own repository. In the latter case, if the developers want some central repository they have to designate one of them as the authoritative one. This is a social issue; AFAIK none of them has a provision to dedicate one of the repositories as the authoritative one. If you want your commits to migrate to the central repository you would do a push for that. So in a certain sense the push could count as a global commit. But this is certainly not the only possible workflow. -- Piet van Oostrum <piet@cs.uu.nl> URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: piet@vanoostrum.org ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 18:05 ` Werner LEMBERG 2008-01-01 18:27 ` Alan Mackenzie @ 2008-01-01 20:53 ` Nick Roberts 2008-01-02 9:53 ` Richard Stallman 2008-01-02 9:53 ` Richard Stallman 2 siblings, 1 reply; 258+ messages in thread From: Nick Roberts @ 2008-01-01 20:53 UTC (permalink / raw) To: Werner LEMBERG; +Cc: esr, acm, eliz, emacs-devel, esr > > o - They must support "batch mode" working, for RMS and others who > > concentrate fiercely on a single activity at a time. > > git has such a batch mode, while CVS has none. So for Richard, git > would be a much better choice than CVS since he could commit very > small units while being off-line. More than that, I think you have a copy of the whole repository locally, so you can look at logs, earlier revisions etc while off-line. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 20:53 ` Nick Roberts @ 2008-01-02 9:53 ` Richard Stallman 2008-01-02 12:24 ` Eric S. Raymond 0 siblings, 1 reply; 258+ messages in thread From: Richard Stallman @ 2008-01-02 9:53 UTC (permalink / raw) To: Nick Roberts; +Cc: esr, emacs-devel, esr, acm, eliz More than that, I think you have a copy of the whole repository locally, so you can look at logs, earlier revisions etc while off-line. That sounds useful. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 9:53 ` Richard Stallman @ 2008-01-02 12:24 ` Eric S. Raymond 2008-01-02 15:19 ` David Kastrup 0 siblings, 1 reply; 258+ messages in thread From: Eric S. Raymond @ 2008-01-02 12:24 UTC (permalink / raw) To: Richard Stallman; +Cc: esr, Nick Roberts, emacs-devel, acm, eliz Richard Stallman <rms@gnu.org>: > More than that, I think you have a copy of the whole repository locally, > so you can look at logs, earlier revisions etc while off-line. > > That sounds useful. It is. All the 3Gs have this property. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 12:24 ` Eric S. Raymond @ 2008-01-02 15:19 ` David Kastrup 2008-01-02 20:35 ` Karl Fogel 2008-01-03 1:18 ` Giorgos Keramidas 0 siblings, 2 replies; 258+ messages in thread From: David Kastrup @ 2008-01-02 15:19 UTC (permalink / raw) To: esr; +Cc: esr, Richard Stallman, Nick Roberts, emacs-devel, acm, eliz "Eric S. Raymond" <esr@thyrsus.com> writes: > Richard Stallman <rms@gnu.org>: >> More than that, I think you have a copy of the whole repository locally, >> so you can look at logs, earlier revisions etc while off-line. >> >> That sounds useful. > > It is. All the 3Gs have this property. But I doubt all of them manage to squeeze all of Emacs' CVS history (actually, more than that, since the Emacs' git repository also contains the non-CVS multi-tty history AFAIK) into 200MB. -- David Kastrup ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 15:19 ` David Kastrup @ 2008-01-02 20:35 ` Karl Fogel 2008-01-02 19:19 ` Andreas Schwab 2008-01-02 19:23 ` Romain Francoise 2008-01-03 1:18 ` Giorgos Keramidas 1 sibling, 2 replies; 258+ messages in thread From: Karl Fogel @ 2008-01-02 20:35 UTC (permalink / raw) To: David Kastrup Cc: esr, Richard Stallman, Nick Roberts, emacs-devel, esr, acm, eliz David Kastrup <dak@gnu.org> writes: > But I doubt all of them manage to squeeze all of Emacs' CVS history > (actually, more than that, since the Emacs' git repository also contains > the non-CVS multi-tty history AFAIK) into 200MB. Only ~280MB for a git clone, for what it's worth. I used Romain Francoise's git mirror of Emacs CVS to determine this: $ git clone git://git.sv.gnu.org/emacs.git Initialized empty Git repository in /home/kfogel/src/emacs/.git/ remote: Generating pack... remote: Done counting 451233 objects. remote: Deltifying 451233 objects... remote: Indexing 451233 objects... remote: Total 451233 (delta 350726), reused 433746 (delta 336579) 100% (451233/451233) done Resolving 350726 deltas... 100% (350726/350726) done Checking 2778 files out... 100% (2778/2778) done $ du -sh emacs 282M emacs $ -Karl ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 20:35 ` Karl Fogel @ 2008-01-02 19:19 ` Andreas Schwab 2008-01-02 19:23 ` Romain Francoise 1 sibling, 0 replies; 258+ messages in thread From: Andreas Schwab @ 2008-01-02 19:19 UTC (permalink / raw) To: Karl Fogel Cc: esr, Richard Stallman, Nick Roberts, emacs-devel, esr, acm, eliz Karl Fogel <kfogel@red-bean.com> writes: > David Kastrup <dak@gnu.org> writes: >> But I doubt all of them manage to squeeze all of Emacs' CVS history >> (actually, more than that, since the Emacs' git repository also contains >> the non-CVS multi-tty history AFAIK) into 200MB. > > Only ~280MB for a git clone, for what it's worth. That includes the checked out files, as it seems. The raw repository is about 220MB (although that is bigger than necessary, better packing can reduce that to 182MB). Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 20:35 ` Karl Fogel 2008-01-02 19:19 ` Andreas Schwab @ 2008-01-02 19:23 ` Romain Francoise 1 sibling, 0 replies; 258+ messages in thread From: Romain Francoise @ 2008-01-02 19:23 UTC (permalink / raw) To: Karl Fogel Cc: esr, Richard Stallman, Nick Roberts, emacs-devel, esr, acm, eliz Karl Fogel <kfogel@red-bean.com> writes: > I used Romain Francoise's git mirror of Emacs CVS [...] Actually this service is run by Jim Meyering, I'm just a happy user. :-) ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 15:19 ` David Kastrup 2008-01-02 20:35 ` Karl Fogel @ 2008-01-03 1:18 ` Giorgos Keramidas 2008-01-03 7:55 ` David Kastrup 1 sibling, 1 reply; 258+ messages in thread From: Giorgos Keramidas @ 2008-01-03 1:18 UTC (permalink / raw) To: David Kastrup Cc: esr, Richard Stallman, Nick Roberts, emacs-devel, esr, acm, eliz On 2008-01-02 16:19, David Kastrup <dak@gnu.org> wrote: >"Eric S. Raymond" <esr@thyrsus.com> writes: >> Richard Stallman <rms@gnu.org>: >>> More than that, I think you have a copy of the whole repository >>> locally, so you can look at logs, earlier revisions etc while >>> off-line. >>> >>> That sounds useful. >> >> It is. All the 3Gs have this property. > > But I doubt all of them manage to squeeze all of Emacs' CVS history > (actually, more than that, since the Emacs' git repository also contains > the non-CVS multi-tty history AFAIK) into 200MB. I have a locally converted `HEAD' from CVS -> Mercurial which contains all the history of the Emacs trunk, and is now at 138 MB: keramida@kobe:/home/keramida/hg/emacs/head$ du -skh .hg 138M .hg keramida@kobe:/home/keramida/hg/emacs/head$ This repository doesn't contain *all* the branches which have ever existed for Emacs, but a pair of branches won't really bloat the history above 200 MB easily. Both Git and Mercurial are trying hard to store large histories in an efficient manner. They make different trade-offs, so some things will invariably end up different, but there is a lot of cross-pollination between the two systems, and that's usually a good thing :) HTH, Giorgos ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-03 1:18 ` Giorgos Keramidas @ 2008-01-03 7:55 ` David Kastrup 0 siblings, 0 replies; 258+ messages in thread From: David Kastrup @ 2008-01-03 7:55 UTC (permalink / raw) To: Giorgos Keramidas Cc: esr, Richard Stallman, Nick Roberts, emacs-devel, esr, acm, eliz Giorgos Keramidas <keramida@ceid.upatras.gr> writes: > On 2008-01-02 16:19, David Kastrup <dak@gnu.org> wrote: > >> But I doubt all of them manage to squeeze all of Emacs' CVS history >> (actually, more than that, since the Emacs' git repository also contains >> the non-CVS multi-tty history AFAIK) into 200MB. > > I have a locally converted `HEAD' from CVS -> Mercurial which contains > all the history of the Emacs trunk, and is now at 138 MB: > > keramida@kobe:/home/keramida/hg/emacs/head$ du -skh .hg > 138M .hg > keramida@kobe:/home/keramida/hg/emacs/head$ > > This repository doesn't contain *all* the branches which have ever > existed for Emacs, but a pair of branches won't really bloat the history > above 200 MB easily. Well, some of the branches have significant independent work and a looooong history in them. Nevertheless, the usage would appear in the same ballpark here. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 18:05 ` Werner LEMBERG 2008-01-01 18:27 ` Alan Mackenzie 2008-01-01 20:53 ` Nick Roberts @ 2008-01-02 9:53 ` Richard Stallman 2008-01-02 10:03 ` David Kastrup ` (2 more replies) 2 siblings, 3 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-02 9:53 UTC (permalink / raw) To: Werner LEMBERG; +Cc: esr, acm, eliz, emacs-devel, esr Would ONE of you please email me git intro documentation? (Please check and see if someone else has already said he has done so, before sending it again.) ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 9:53 ` Richard Stallman @ 2008-01-02 10:03 ` David Kastrup 2008-01-02 10:05 ` Tassilo Horn 2008-01-02 14:26 ` Óscar Fuentes 2 siblings, 0 replies; 258+ messages in thread From: David Kastrup @ 2008-01-02 10:03 UTC (permalink / raw) To: rms; +Cc: esr, emacs-devel, esr, acm, eliz Richard Stallman <rms@gnu.org> writes: > Would ONE of you please email me git intro documentation? > (Please check and see if someone else has already said he > has done so, before sending it again.) I'll be doing so. -- David Kastrup ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 9:53 ` Richard Stallman 2008-01-02 10:03 ` David Kastrup @ 2008-01-02 10:05 ` Tassilo Horn 2008-01-02 11:31 ` Alan Mackenzie 2008-01-02 14:26 ` Óscar Fuentes 2 siblings, 1 reply; 258+ messages in thread From: Tassilo Horn @ 2008-01-02 10:05 UTC (permalink / raw) To: rms; +Cc: esr, emacs-devel, esr, acm, eliz Richard Stallman <rms@gnu.org> writes: > Would ONE of you please email me git intro documentation? > (Please check and see if someone else has already said he > has done so, before sending it again.) I'll do so now. Bye, Tassilo ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 10:05 ` Tassilo Horn @ 2008-01-02 11:31 ` Alan Mackenzie 2008-01-02 11:28 ` Tassilo Horn 0 siblings, 1 reply; 258+ messages in thread From: Alan Mackenzie @ 2008-01-02 11:31 UTC (permalink / raw) To: emacs-devel Hi, Tassilo! On Wed, Jan 02, 2008 at 11:05:27AM +0100, Tassilo Horn wrote: > Richard Stallman <rms@gnu.org> writes: > > Would ONE of you please email me git intro documentation? (Please > > check and see if someone else has already said he has done so, > > before sending it again.) > I'll do so now. Could you post the URL too, please? Thanks! > Tassilo -- Alan Mackenzie (Nuremberg, Germany) ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 11:31 ` Alan Mackenzie @ 2008-01-02 11:28 ` Tassilo Horn 0 siblings, 0 replies; 258+ messages in thread From: Tassilo Horn @ 2008-01-02 11:28 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel Alan Mackenzie <acm@muc.de> writes: Hi Alan, >> > Would ONE of you please email me git intro documentation? (Please >> > check and see if someone else has already said he has done so, >> > before sending it again.) > >> I'll do so now. > > Could you post the URL too, please? Sure. http://git.or.cz/#documentation Or to get directly to the tutorial http://www.kernel.org/pub/software/scm/git/docs/tutorial.html Bye, Tassilo ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 9:53 ` Richard Stallman 2008-01-02 10:03 ` David Kastrup 2008-01-02 10:05 ` Tassilo Horn @ 2008-01-02 14:26 ` Óscar Fuentes 2008-01-02 19:48 ` Karl Fogel 2 siblings, 1 reply; 258+ messages in thread From: Óscar Fuentes @ 2008-01-02 14:26 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org> writes: > Would ONE of you please email me git intro documentation? > (Please check and see if someone else has already said he > has done so, before sending it again.) Please do not focus too much on git. AFAIK it is not the most easy to use decentralized VCS and its support for non-*nix systems is weak. I'll suggest you use Mercurial for learning what a decentralized VCS can do. The basic idea is the same for all dVCS's. Of course the interface and implementation trade-offs varies among them. Mercurial: http://www.selenic.com/mercurial/wiki/ Focus on UnderstandingMercurial and the Tutorial. CvsInfo may be useful too. Bazaar is another dVCS. On its website there are some articles interesting articles: http://bazaar-vcs.org/Articles -- Oscar ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 14:26 ` Óscar Fuentes @ 2008-01-02 19:48 ` Karl Fogel 2008-01-02 18:43 ` Andreas Schwab ` (2 more replies) 0 siblings, 3 replies; 258+ messages in thread From: Karl Fogel @ 2008-01-02 19:48 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > Please do not focus too much on git. AFAIK it is not the most easy to > use decentralized VCS and its support for non-*nix systems is weak. > > I'll suggest you use Mercurial for learning what a decentralized VCS can > do. The basic idea is the same for all dVCS's. Of course the interface > and implementation trade-offs varies among them. > > [...] I'd been staying out of this thread, mostly because it's going in a direction I like anyway :-). But I too would love to see Emacs switch to a dVCS like Mercurial or git. The dVCS model would fit Emacs development very well, and it would be especially good for Richard, once he learns the new ropes, because of the tremendous offline capability. (Disclaimer: I'm a Subversion developer, and like Subversion, but it's not the best hammer for every nail.) Regarding storage issues: David Kastrup <dak@gnu.org> wrote: > But I doubt all of them manage to squeeze all of Emacs' CVS history > (actually, more than that, since the Emacs' git repository also contains > the non-CVS multi-tty history AFAIK) into 200MB. Maybe not 200MB, but still probably less than 400MB; possibly far less. dVCS repositories are surprisingly small for all that history ("surprising" to those who aren't used to how they do their storage, anyway). I tried to do a test conversion of the Emacs CVS repository, but don't see a way to get a full repository tarball from Savannah. If someone can hand me one, I'll do a test conversion and report back. -Karl ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 19:48 ` Karl Fogel @ 2008-01-02 18:43 ` Andreas Schwab 2008-01-02 22:10 ` Alfred M. Szmidt 2008-01-03 1:21 ` Giorgos Keramidas 2 siblings, 0 replies; 258+ messages in thread From: Andreas Schwab @ 2008-01-02 18:43 UTC (permalink / raw) To: Karl Fogel; +Cc: Óscar Fuentes, emacs-devel Karl Fogel <kfogel@red-bean.com> writes: > I tried to do a test conversion of the Emacs CVS repository, but don't > see a way to get a full repository tarball from Savannah. You can rsync it (use rsync://cvs.sv.gnu.org for a list of modules). Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 19:48 ` Karl Fogel 2008-01-02 18:43 ` Andreas Schwab @ 2008-01-02 22:10 ` Alfred M. Szmidt 2008-01-03 2:58 ` Karl Fogel 2008-01-03 1:21 ` Giorgos Keramidas 2 siblings, 1 reply; 258+ messages in thread From: Alfred M. Szmidt @ 2008-01-02 22:10 UTC (permalink / raw) To: Karl Fogel; +Cc: ofv, emacs-devel I tried to do a test conversion of the Emacs CVS repository, but don't see a way to get a full repository tarball from Savannah. If someone can hand me one, I'll do a test conversion and report back. | rsync -av cvs.gnu.org::sources/emacs . Someone already noted that there was already a git repository of Emacs on savannah: | git clone git://git.sv.gnu.org/emacs.git ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 22:10 ` Alfred M. Szmidt @ 2008-01-03 2:58 ` Karl Fogel 0 siblings, 0 replies; 258+ messages in thread From: Karl Fogel @ 2008-01-03 2:58 UTC (permalink / raw) To: ams; +Cc: ofv, emacs-devel "Alfred M. Szmidt" <ams@gnu.org> writes: > I tried to do a test conversion of the Emacs CVS repository, but don't > see a way to get a full repository tarball from Savannah. If someone > can hand me one, I'll do a test conversion and report back. > > | rsync -av cvs.gnu.org::sources/emacs . > > Someone already noted that there was already a git repository of Emacs > on savannah: > > | git clone git://git.sv.gnu.org/emacs.git Oh, I already followed up in the original thread with the answer. Here it is: > David Kastrup <dak@gnu.org> writes: > > But I doubt all of them manage to squeeze all of Emacs' CVS history > > (actually, more than that, since the Emacs' git repository also contains > > the non-CVS multi-tty history AFAIK) into 200MB. > > Only ~280MB for a git clone, for what it's worth. I used Romain > Francoise's [correct: Jim Meyering's] git mirror of Emacs CVS to > determine this: > > $ git clone git://git.sv.gnu.org/emacs.git > Initialized empty Git repository in /home/kfogel/src/emacs/.git/ > remote: Generating pack... > remote: > Done counting 451233 objects. > remote: Deltifying 451233 objects... > remote: > Indexing 451233 objects... > remote: Total 451233 (delta 350726), reused 433746 (delta 336579) > 100% (451233/451233) done > Resolving 350726 deltas... > 100% (350726/350726) done > Checking 2778 files out... > 100% (2778/2778) done > $ du -sh emacs > 282M emacs > $ -Karl ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 19:48 ` Karl Fogel 2008-01-02 18:43 ` Andreas Schwab 2008-01-02 22:10 ` Alfred M. Szmidt @ 2008-01-03 1:21 ` Giorgos Keramidas 2008-01-03 9:14 ` Andreas Schwab 2 siblings, 1 reply; 258+ messages in thread From: Giorgos Keramidas @ 2008-01-03 1:21 UTC (permalink / raw) To: Karl Fogel; +Cc: Oscar Fuentes, emacs-devel On 2008-01-02 11:48, Karl Fogel <kfogel@red-bean.com> wrote: > I tried to do a test conversion of the Emacs CVS repository, but don't > see a way to get a full repository tarball from Savannah. If someone > can hand me one, I'll do a test conversion and report back. I use the following script to rsync the repository now and then: #!/bin/sh # # Mirror the CVS repository of Emacs. Information about rsync and # the rsync incantation to mirror the repo, obtained from: # # Ken Raeburn, raeburn at raeburn.org # Message-Id: <FC340194-0902-4349-8AC8-8E5F4E891DD4@raeburn.org> # on emacs-devel # rsync --delete --force --recursive \ --links --safe-links --hard-links --times \ --compress --progress -vv --stats \ cvs.savannah.gnu.org::sources/emacs/ /home/emacs/ Many belated thanks to Ken Raeburn, who initially pointed me at this method of obtaining a local CVS repository :) ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-03 1:21 ` Giorgos Keramidas @ 2008-01-03 9:14 ` Andreas Schwab 2008-01-03 10:57 ` Giorgos Keramidas 0 siblings, 1 reply; 258+ messages in thread From: Andreas Schwab @ 2008-01-03 9:14 UTC (permalink / raw) To: Giorgos Keramidas; +Cc: Karl Fogel, Oscar Fuentes, emacs-devel Giorgos Keramidas <keramida@ceid.upatras.gr> writes: > rsync --delete --force --recursive \ > --links --safe-links --hard-links --times \ > --compress --progress -vv --stats \ > cvs.savannah.gnu.org::sources/emacs/ /home/emacs/ Don't use --hard-links, it is expensive and a CVS repository should never contain hard links. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-03 9:14 ` Andreas Schwab @ 2008-01-03 10:57 ` Giorgos Keramidas 0 siblings, 0 replies; 258+ messages in thread From: Giorgos Keramidas @ 2008-01-03 10:57 UTC (permalink / raw) To: Andreas Schwab; +Cc: Karl Fogel, Oscar Fuentes, emacs-devel On 2008-01-03 10:14, Andreas Schwab <schwab@suse.de> wrote: > Giorgos Keramidas <keramida@ceid.upatras.gr> writes: > > rsync --delete --force --recursive \ > > --links --safe-links --hard-links --times \ > > --compress --progress -vv --stats \ > > cvs.savannah.gnu.org::sources/emacs/ /home/emacs/ > > Don't use --hard-links, it is expensive and a CVS repository should > never contain hard links. Thanks, I've updated the local script :) ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 17:11 ` Alan Mackenzie 2008-01-01 18:05 ` Werner LEMBERG @ 2008-01-01 19:37 ` Eric S. Raymond 2008-01-01 21:46 ` Alan Mackenzie ` (3 more replies) 2008-01-01 22:01 ` Romain Francoise 2 siblings, 4 replies; 258+ messages in thread From: Eric S. Raymond @ 2008-01-01 19:37 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Eric S. Raymond, Eli Zaretskii, emacs-devel Alan Mackenzie <acm@muc.de>: > A few suggestions: > o - Emacs is implemented in a wierd special purpose language. Right. And how many hundreds of thousands of users do we have teaching themselves beginning elisp by doing small local customizations to their .emacs files? No, that won't hold water. > o - Emacs is already so good that it's difficult to see room for new > features. I had to rewrite VC-mode recently because it couldn't drive modern VCSes. When I did so I discovered that several key functions had been hacked into a state of severe mal-design. No, "Emacs is too good" won't work either. > o - Much core Emacs code has, despite RMS's good sense and emphasis on > simplicity, become tortuous and difficult to get into. There is probably something to this. > o - Emacs is a victim of its own success - as its new features make it > steadily easier to use, it becomes steadily more intricate and thus > harder to learn. A non-user of Emacs cannot become an Emacs hacker. And to this. Though why it's a problem that non-Emacs-users can't hack Emacs when we have so many users, I don't see. But while your last two problems contribute to the mess we're in, they're not sufficient to explain it. > I'd think it's worth emphasising that CVS is _NOT_ a poor tool; it's an > exceptionally flexible, solid and reliable one, free from feature bloat, > and I'm grateful indeed to the hackers who've maintained it over the > decades. Clearly you've never used a decently-designed VCS. Do you have any idea of the kind of horrible shite CVS can land you in if you try something as basic as renaming a file? I'm gathering not, and you should perhaps be grateful for your ignorance. It's not just that the operation isn't supported, it's that the crocky workarounds recommended in the CVS manual are highly likely to corrupt your repo. CVS's key hackers abandoned it to start the Subversion project in 2000 because they had concluded CVS was unsalvageably bad. I've studied how CVS works internally for a survey paper on VCSes I'm doing, and -- believe me -- they were right to do so. > o - They must support "batch mode" working, for RMS and others who > concentrate fiercely on a single activity at a time. This problem doesn't have any technical solution. What you appear to be thinking of as "batch mode" (disappear into a cave for months at a time) is not compatible with the communications practices we need to move to in order to make the Emacs project agile and responsive again. In particular, it's incompatible with engaging our users in real-time via IRC and other messaging channels. There's still a role for people with a "batch mode" working style, but it's more in the background working on large semi-detached projects. Project leads have to face the world. > o - They must, like Emacs, be fully usable on a text console without a > mouse as well as in X. There are at least 3 hackers here who prefer > such a setup. This *does* have a technical solution: lynx. Or links. Text-mode browsers aren't what I'd call pleasant compared to graphical ones, but they are usable. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 19:37 ` Eric S. Raymond @ 2008-01-01 21:46 ` Alan Mackenzie 2008-01-01 22:49 ` Eric S. Raymond 2008-01-02 8:35 ` Tassilo Horn 2008-01-02 5:54 ` John S. Yates, Jr. ` (2 subsequent siblings) 3 siblings, 2 replies; 258+ messages in thread From: Alan Mackenzie @ 2008-01-01 21:46 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Eric S. Raymond, Eli Zaretskii, emacs-devel Hi, Eric! On Tue, Jan 01, 2008 at 02:37:32PM -0500, Eric S. Raymond wrote: > Alan Mackenzie <acm@muc.de>: > > A few suggestions: [ .... ] > > o - Emacs is already so good that it's difficult to see room for new > > features. > I had to rewrite VC-mode recently because it couldn't drive modern > VCSes. When I did so I discovered that several key functions had been > hacked into a state of severe mal-design. No, "Emacs is too good" > won't work either. I'm trying to look at things from the point of view of an outsider. Yes, there's LOTS of laborious maintenance to be done, but the newbie doesn't see this (due to the immense amount of testing in the immensely long release cycle). Emacs DOES need new features (refactoring, better browsing, etc.), but those are rarely obvious to the new people we need. [ .... ] > > o - Emacs is a victim of its own success - as its new features make it > > steadily easier to use, it becomes steadily more intricate and thus > > harder to learn. A non-user of Emacs cannot become an Emacs hacker. > And to this. Though why it's a problem that non-Emacs-users can't hack Emacs > when we have so many users, I don't see. It's more of a long term problem, in that the number of Emacs users might be gradually declining. I'm only guessing here though, I don't know. > But while your last two problems contribute to the mess we're in, they're > not sufficient to explain it. Er, I never meant them to be. I was throwing around some ideas for discussion. > > I'd think it's worth emphasising that CVS is _NOT_ a poor tool; it's > > an exceptionally flexible, solid and reliable one, free from feature > > bloat, and I'm grateful indeed to the hackers who've maintained it > > over the decades. > Clearly you've never used a decently-designed VCS. Do you have any > idea of the kind of horrible shite CVS can land you in if you try > something as basic as renaming a file? Yes. > I'm gathering not, and you should perhaps be grateful for your > ignorance. It's not just that the operation isn't supported, it's > that the crocky workarounds recommended in the CVS manual are highly > likely to corrupt your repo. HEY, THAT'S NOT FAIR!!!! You've distorted my post by selective deletion. When I said CVS was good, I qualified clearly what I meant by reference to hammers, nails and screws. The steam engine was a wonderful invention too, but no modern railway system would now deploy one as prime choice of traction. And no, I don't think I ever have used a good VCS, and you and one or two others have just made me aware that I'm missing something worthwhile. Cut me some slack, please. [ .... ] > > o - They must support "batch mode" working, for RMS and others who > > concentrate fiercely on a single activity at a time. > This problem doesn't have any technical solution. What you appear to > be thinking of as "batch mode" (disappear into a cave for months at a > time) is not compatible with the communications practices we need to > move to in order to make the Emacs project agile and responsive again. > In particular, it's incompatible with engaging our users in real-time > via IRC and other messaging channels. > There's still a role for people with a "batch mode" working style, but > it's more in the background working on large semi-detached projects. > Project leads have to face the world. OK, here's where you need to persuade me (?us). There have been lots of bugs in CC Mode where I've had to dig myself in without distractions for hours at a time, sometimes days, to resolve; bits of Emacs are like that - some hackers are like this. I've been able to emerge and engage in the mailing list. I don't think I could do this with a rapid-fire IRC instead of email. Richard has said he couldn't spare the time for this style of hacking. I believe him. It seems that there will be losses as well as gains from moving to IIRC. How convinced are you that the gains will outweigh the losses? Is there perhaps a third way which combines the good bits and minimises the bad bits of the other two? > > o - They must, like Emacs, be fully usable on a text console without a > > mouse as well as in X. There are at least 3 hackers here who prefer > > such a setup. > This *does* have a technical solution: lynx. Or links. Text-mode > browsers aren't what I'd call pleasant compared to graphical ones, but > they are usable. A web browser is for browsing the web, and is pretty cruddy for anything else. For email you'd use mutt, for documentation C-h i, for usenet tin or slrn, and so on. Surely there's a purpose built tty client for IRC. > <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 21:46 ` Alan Mackenzie @ 2008-01-01 22:49 ` Eric S. Raymond 2008-01-02 17:05 ` Mark A. Hershberger 2008-01-03 9:49 ` Richard Stallman 2008-01-02 8:35 ` Tassilo Horn 1 sibling, 2 replies; 258+ messages in thread From: Eric S. Raymond @ 2008-01-01 22:49 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Eric S. Raymond, Eli Zaretskii, emacs-devel Alan Mackenzie <acm@muc.de>: > Emacs DOES need new features (refactoring, better > browsing, etc.), but those are rarely obvious to the new people we need. I think more direct interaction between the users and the developer community might help with this. On the Wesnoth project, most of our new devs are people who have been lurking on #wesnoth-dev for a while before they send their first patch. So they've been listening to the developers talk among themselves about what needs done. A public bugtracker will help here, too. Another common entry path is for someone who might want to get more involved to pick a feature request, do it, and send a patch to the dev list. > It's more of a long term problem, in that the number of Emacs users might > be gradually declining. I'm only guessing here though, I don't know. I have no data on this, just an uneasy gut feeling. > HEY, THAT'S NOT FAIR!!!! You've distorted my post by selective deletion. > When I said CVS was good, I qualified clearly what I meant by reference > to hammers, nails and screws. Er....I was not the only person to read your note as fairly unqualified praise of CVS. But never mind. > OK, here's where you need to persuade me (?us). There have been lots of > bugs in CC Mode where I've had to dig myself in without distractions for > hours at a time, sometimes days, to resolve; bits of Emacs are like that > - some hackers are like this. I've been able to emerge and engage in the > mailing list. I don't think I could do this with a rapid-fire IRC > instead of email. Richard has said he couldn't spare the time for this > style of hacking. I believe him. I don't experience any difficulty digging in like this. When you need to, you tell your IRC client "/away" and it announces to the channel that you are away from keyboard. When you're ready to surface, skim the IRC scroll buffer and type "/back". If your experience is like mine, you'll find you start being able to glance at the chatter occasionally without breaking your flow, the same way you can sort of half-consciously monitor quiet speech around you without breaking conversation until you hear something that tells you you need to pay attention. > A web browser is for browsing the web, and is pretty cruddy for anything > else. For email you'd use mutt, for documentation C-h i, for usenet tin > or slrn, and so on. Surely there's a purpose built tty client for IRC. Oh, yes, sure. Boatloads of them. ircii is one of the best known. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 22:49 ` Eric S. Raymond @ 2008-01-02 17:05 ` Mark A. Hershberger 2008-01-03 9:49 ` Richard Stallman 1 sibling, 0 replies; 258+ messages in thread From: Mark A. Hershberger @ 2008-01-02 17:05 UTC (permalink / raw) To: emacs-devel "Eric S. Raymond" <esr@thyrsus.com> writes: >> It's more of a long term problem, in that the number of Emacs users might >> be gradually declining. I'm only guessing here though, I don't know. > > I have no data on this, just an uneasy gut feeling. http://google.com/trends?q=emacs The above chart shows that searches for the term “emacs” have been declining over the past 3 years. I suspect part of this is due to the growth of IDEs like Eclipse. This isn't proof that use of Emacs is declining, of course. But it does indicate that people might not be as interested to learn about it as they were in the past. (If you add “vim” to the chart, you can see that queries for it have stayed more constant. The term “vi” does not have as clear a meaning — most of the hits are for the sixth version of something.) -- http://hexmode.com/ GPG Fingerprint: 7E15 362D A32C DFAB E4D2 B37A 735E F10A 2DFC BFF5 My happiness grows in direct proportion to my acceptance, and in inverse proportion to my expectations. -- Michael J. Fox ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 22:49 ` Eric S. Raymond 2008-01-02 17:05 ` Mark A. Hershberger @ 2008-01-03 9:49 ` Richard Stallman 1 sibling, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-03 9:49 UTC (permalink / raw) To: esr; +Cc: acm, eliz, emacs-devel, esr If your experience is like mine, you'll find you start being able to glance at the chatter occasionally without breaking your flow, the same way you can sort of half-consciously monitor quiet speech around you without breaking conversation until you hear something that tells you you need to pay attention. My brain doesn't work like that. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 21:46 ` Alan Mackenzie 2008-01-01 22:49 ` Eric S. Raymond @ 2008-01-02 8:35 ` Tassilo Horn 1 sibling, 0 replies; 258+ messages in thread From: Tassilo Horn @ 2008-01-02 8:35 UTC (permalink / raw) To: emacs-devel Alan Mackenzie <acm@muc.de> writes: Hi Alan, >> > o - They must, like Emacs, be fully usable on a text console >> > without a mouse as well as in X. There are at least 3 hackers here >> > who prefer such a setup. > >> This *does* have a technical solution: lynx. Or links. Text-mode >> browsers aren't what I'd call pleasant compared to graphical ones, >> but they are usable. emacs-w3m is quite good. I already used it to file some bug reports at the kde and gentoo bugzillas. > A web browser is for browsing the web, and is pretty cruddy for > anything else. For email you'd use mutt, for documentation C-h i, for > usenet tin or slrn, and so on. Surely there's a purpose built tty > client for IRC. You can do all of those jobs in a stock emacs: - Mail: Gnus, VM, rmail - News: Gnus - Web: emacs-w3m (ok, that's not stock...) - IRC: ERC, rcirc Bye, Tassilo ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 19:37 ` Eric S. Raymond 2008-01-01 21:46 ` Alan Mackenzie @ 2008-01-02 5:54 ` John S. Yates, Jr. 2008-01-02 11:52 ` Eric S. Raymond 2008-01-03 9:50 ` Richard Stallman 2008-01-02 8:51 ` tomas 2008-01-02 9:53 ` Richard Stallman 3 siblings, 2 replies; 258+ messages in thread From: John S. Yates, Jr. @ 2008-01-02 5:54 UTC (permalink / raw) To: esr; +Cc: emacs-devel On Tue, 1 Jan 2008 14:37:32 -0500, esr wrote: > Do you have any idea of the kind of horrible shite CVS can > land you in if you try something as basic as renaming a file? Speaking from experience on multiple projects, a pernicious CVS effect is to install a reluctance to rename. This is tantamount to banning any large scale refactoring. And that is ultimately extremely damaging to a long-lived code base under truly active development. /john ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 5:54 ` John S. Yates, Jr. @ 2008-01-02 11:52 ` Eric S. Raymond 2008-01-03 9:50 ` Richard Stallman 1 sibling, 0 replies; 258+ messages in thread From: Eric S. Raymond @ 2008-01-02 11:52 UTC (permalink / raw) To: John S. Yates, Jr.; +Cc: emacs-devel John S. Yates, Jr. <john@yates-sheets.org>: > Speaking from experience on multiple projects, a pernicious CVS > effect is to install a reluctance to rename. This is tantamount > to banning any large scale refactoring. And that is ultimately > extremely damaging to a long-lived code base under truly active > development. Emphatically agreed. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 5:54 ` John S. Yates, Jr. 2008-01-02 11:52 ` Eric S. Raymond @ 2008-01-03 9:50 ` Richard Stallman 1 sibling, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-03 9:50 UTC (permalink / raw) To: John S. Yates, Jr.; +Cc: esr, emacs-devel Speaking from experience on multiple projects, a pernicious CVS effect is to install a reluctance to rename. This is tantamount to banning any large scale refactoring. And that is ultimately extremely damaging to a long-lived code base under truly active development. I agree that this is a drawback of CVS, but in Emacs we have not let it stop us from moving files around. We've done substantial amounts of that recently. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 19:37 ` Eric S. Raymond 2008-01-01 21:46 ` Alan Mackenzie 2008-01-02 5:54 ` John S. Yates, Jr. @ 2008-01-02 8:51 ` tomas 2008-01-02 9:53 ` Richard Stallman 3 siblings, 0 replies; 258+ messages in thread From: tomas @ 2008-01-02 8:51 UTC (permalink / raw) To: Eric S. Raymond Cc: Alan Mackenzie, Eli Zaretskii, emacs-devel, Eric S. Raymond -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Jan 01, 2008 at 02:37:32PM -0500, Eric S. Raymond wrote: [...] > > o - They must, like Emacs, be fully usable on a text console without a > > mouse as well as in X. There are at least 3 hackers here who prefer > > such a setup. > > This *does* have a technical solution: lynx. Or links. Text-mode > browsers aren't what I'd call pleasant compared to graphical ones, but > they are usable. I have to take issue with this last one. Whereas I'm far from 'console bigot' (I do enjoy Emacs on X far more than on console), I cringe when I have to use those badly done, Javascript and cookie-laden Web-2.0 interfaces. Trac -- ackphth. GUI != browser. And I think we'd be better off separating all those layers and picking whatever suits us. Why not http without html? Or html without Javascript? Texinfo-over-http anyone? Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFHe1CBBcgs9XrR2kYRAv7eAJ4yVuwhJHcnrufo5DUHrMg6X+mKeQCdFt5F V5wPIU6NVEg0xSaRr16uu0I= =cFNy -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 19:37 ` Eric S. Raymond ` (2 preceding siblings ...) 2008-01-02 8:51 ` tomas @ 2008-01-02 9:53 ` Richard Stallman 3 siblings, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-02 9:53 UTC (permalink / raw) To: esr; +Cc: acm, eliz, emacs-devel, esr There's still a role for people with a "batch mode" working style, but it's more in the background working on large semi-detached projects. Project leads have to face the world. I will not choose future Emacs maintainers based on their willingness to work in that particular way. Any future Emacs maintainers, will choose the tools that fit their styles and their lives, just as I choose the ones that fit mine. It is fine to suggest tools for use to use, but don't go beyond suggesting. You must take no for an answer when that is the answer you get. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 17:11 ` Alan Mackenzie 2008-01-01 18:05 ` Werner LEMBERG 2008-01-01 19:37 ` Eric S. Raymond @ 2008-01-01 22:01 ` Romain Francoise 2 siblings, 0 replies; 258+ messages in thread From: Romain Francoise @ 2008-01-01 22:01 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Eric S. Raymond, emacs-devel Alan Mackenzie <acm@muc.de> writes: > I'd think it's worth emphasising that CVS is _NOT_ a poor tool [...] Your clock is off, today's January 1st, not April 1st. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-30 12:22 What a modern collaboration toolkit looks like Eric S. Raymond ` (2 preceding siblings ...) 2007-12-31 4:31 ` Eli Zaretskii @ 2007-12-31 13:11 ` Alan Mackenzie 2007-12-31 13:24 ` Miles Bader 2007-12-31 15:25 ` Eric S. Raymond 2008-01-19 17:45 ` Jari Aalto 4 siblings, 2 replies; 258+ messages in thread From: Alan Mackenzie @ 2007-12-31 13:11 UTC (permalink / raw) To: Eric S. Raymond; +Cc: emacs-devel Happy New Year, Eric and Emacs! On Sun, Dec 30, 2007 at 07:22:17AM -0500, Eric S. Raymond wrote: > ...., I think it will be useful if I start by giving everybody a clear > idea of the potential benefits of changing our practices. > I'm going to describe the collaboration toolkit on another project > where I happen to be a senior dev, called Battle For Wesnoth. You can > find the project at <http://www.wesnoth.org/>. > This is a typical modern open-source project. Emacs is an atypical, very old, piece of free software. Wesnoth seems to be about 5 years old. (I haven't found the repository online.) This has some bearing on the differences in development processes. > .... Here are the collaborative tools we use every day: > * Source control with Subversion > * A bug tracker > * A very active IRC channel used for routine dev chatter > * A dev mailing list, used mostly for white papers and long proposals > * Web forums where a large user community hangs out > * Subversion commits are echoed to IRC in real time by a monitor bot > * Subversion commits that reference a bug append a comment to the tracker > * A bot on IRC that you can query with a bug number and get a tracker URL. > Here are some of the ways my workflow on Wesnoth differs from my > workflow on Emacs: > 1. When I do a commit of changes to several files, the entire changeset > is saved as a unit with a single change comment attached to it. I would appreciate having this in Emacs. > a) That change can be referenced, through its Subversion revision ID. > (So, for example, "Hey boucman, your r22615 broke linger mode!") Hopefully, people are considerate enough not to do this too often; continually having to look somewhere else to get context is not nice. > b) That change can be backed out as a unit. That's fine if nearly all changes are independent. In Emacs, I think, this is not the case. The codebase is extremely old, and clean structuring has in many cases been lost. (But, hey, for >20 y.o. code, it's not bad). Such easy backing out could lead to problems. [ .... ] > 2. My commit is also echoed to the IRC channel, where there are almost > never fewer than three or four devs hanging out as they hack, chatting > in real time. Review tends to happen instantly. What about fixes that are too big for instant review? Emacs has lots of bugs (and often fixes ;-) that are barely tractable, so that the slower pace of email seems a better fit. [ .... ] > The effect of all these tools is more than the sum of its parts. > One huge one is simply that devs can choose to spend time picking bugs > off the tracker and nailing them, with basically zero process friction. > Another is that we routinely hash out serious design and coding issues > in real time, because everyone on the chat channel can share hyperlinks > to the codebase, the commit history, the bug tracker, and posts > on the user forums. I've no experience of IIRC. But doesn't this way of working mean continually dancing from one thing to another? I don't do that very well. The "hyperlinks" bit sounds like you have to look at 3 or 4 things simultaneously to be able to synthesise a context. How does this working style work for difficult problems? > Yet a third is that when we decide to do it, we can converge on a > releasable state with almost absurd ease. Like, Ivanovic (our release > manager) will announce "Point release scheduled this coming Wednesday" > and everyone will pretty much flip into bug-stomping mode. The tracker > bug list tends to shrink dramatically when this happens -- not only do > we get prepared for release but *we know we've done so*. Eric, how well do you think this could work at all for Emacs? > More generally, development happens *fast*. I don't have to wait weeks > to find out whether other devs think of an idea. Commonly I know > within minutes. On emacs-devel, this takes hours, not weeks. At any given time, most Emacs developers are either asleep or doing other things (like earning their living). Doesn't this quick-fire style end up excluding lots of hackers from participation? > The Wesnoth devs are good but not exceptionally so, and we're weighed > down by a crappy implementation language (C++). Yuck!! > Nevertheless our productivity, in terms of goals achieved per hour of > work, is quite high. That's because our collaboration tools support > everything we do without imposing noticeable process friction. This > makes us dramatically more effective as individuals and as a group than > we could possibly be without them. Might it also be because your code base is still young, clean and flexible? > Lessons for the Emacs project? Hell, yes. But I'm not going to write > that rant until y'all have had a little time to absorb this description > of how things can be. I'll look forward to that! We'd all welcome a process for releasing every few months rather than twice a decade. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 13:11 ` Alan Mackenzie @ 2007-12-31 13:24 ` Miles Bader 2007-12-31 13:44 ` Alan Mackenzie ` (2 more replies) 2007-12-31 15:25 ` Eric S. Raymond 1 sibling, 3 replies; 258+ messages in thread From: Miles Bader @ 2007-12-31 13:24 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Eric S. Raymond, emacs-devel Alan Mackenzie <acm@muc.de> writes: >> Yet a third is that when we decide to do it, we can converge on a >> releasable state with almost absurd ease. Like, Ivanovic (our release >> manager) will announce "Point release scheduled this coming Wednesday" >> and everyone will pretty much flip into bug-stomping mode. The tracker >> bug list tends to shrink dramatically when this happens -- not only do >> we get prepared for release but *we know we've done so*. > > Eric, how well do you think this could work at all for Emacs? I suspect that 90% of the difference in "responsiveness" between the two projects has to do with the people (and numbers of people) involved, not with the tools being used. Emacs has a rather small developer base, and most of the developers are fairly busy with other things. A project with lots of developers that are more intensely involved in development is naturally going to be more reponsive. Certainly the tools make _some_ difference, but I think ESR is drastically overestimating how much of one. If Emacs development were at a faster pace (perhaps because the developer base change), then maybe the tools would become a limiting factor, but I don't think they are now. [BTW, one thing I think _would_ be very handy, and easy to implement, would be an IRC channel for Emacs developers, just for those random questions you wanna get a quick answer to sometimes... There's #emacs on irc.freenode.net, but it's more user-level.] -Miles -- "Suppose we've chosen the wrong god. Every time we go to church we're just making him madder and madder." -- Homer Simpson ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 13:24 ` Miles Bader @ 2007-12-31 13:44 ` Alan Mackenzie 2007-12-31 15:45 ` Eric S. Raymond 2007-12-31 15:14 ` Juanma Barranquero 2007-12-31 15:31 ` Eric S. Raymond 2 siblings, 1 reply; 258+ messages in thread From: Alan Mackenzie @ 2007-12-31 13:44 UTC (permalink / raw) To: Miles Bader; +Cc: Eric S. Raymond, emacs-devel Hi, Miles! On Mon, Dec 31, 2007 at 10:24:25PM +0900, Miles Bader wrote: > Alan Mackenzie <acm@muc.de> writes: > >> Yet a third is that when we decide to do it, we can converge on a > >> releasable state with almost absurd ease. Like, Ivanovic (our > >> release manager) will announce "Point release scheduled this coming > >> Wednesday" and everyone will pretty much flip into bug-stomping > >> mode. The tracker bug list tends to shrink dramatically when this > >> happens -- not only do we get prepared for release but *we know > >> we've done so*. > > Eric, how well do you think this could work at all for Emacs? > I suspect that 90% of the difference in "responsiveness" between the > two projects has to do with the people (and numbers of people) > involved, not with the tools being used. What about the code base? > Emacs has a rather small developer base, and most of the developers > are fairly busy with other things. A project with lots of developers > that are more intensely involved in development is naturally going to > be more reponsive. > Certainly the tools make _some_ difference, but I think ESR is > drastically overestimating how much of one. If Emacs development were > at a faster pace (perhaps because the developer base change), then > maybe the tools would become a limiting factor, but I don't think they > are now. My feeling is that better tools would make a substantial difference - perhaps 25% better productivity for me - but nothing like an order of magnitude. Miles, why aren't we all switching to arch? Would it be appropriate for Emacs now? > [BTW, one thing I think _would_ be very handy, and easy to implement, > would be an IRC channel for Emacs developers, just for those random > questions you wanna get a quick answer to sometimes... There's #emacs > on irc.freenode.net, but it's more user-level.] Would anybody be listening? > -Miles -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 13:44 ` Alan Mackenzie @ 2007-12-31 15:45 ` Eric S. Raymond 0 siblings, 0 replies; 258+ messages in thread From: Eric S. Raymond @ 2007-12-31 15:45 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Eric S. Raymond, emacs-devel, Miles Bader Alan Mackenzie <acm@muc.de>: > My feeling is that better tools would make a substantial difference - > perhaps 25% better productivity for me - but nothing like an order of > magnitude. This one is hard for me to evaluate, because Wesnoth is my only C++ project -- more usually I work in Python and C, and my stuff here is Lisp (I was active in the Emacs C core once, but that was long ago). That said, I think your 25% guess is about right as far as lines of code goes. But that wouldn't measure the whole gain -- because with better tools, my coding effort is quite a bit more likely to be directed appropriately. (This is the particular reason bug trackers are really important.) > Miles, why aren't we all switching to arch? Would it be appropriate for > Emacs now? Please not Arch. I just learned it; brilliant ideas, but its interface should be be outlawed under the Geneva convention as a form of torture. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 13:24 ` Miles Bader 2007-12-31 13:44 ` Alan Mackenzie @ 2007-12-31 15:14 ` Juanma Barranquero 2007-12-31 15:31 ` Eric S. Raymond 2 siblings, 0 replies; 258+ messages in thread From: Juanma Barranquero @ 2007-12-31 15:14 UTC (permalink / raw) To: emacs-devel On Dec 31, 2007 2:24 PM, Miles Bader <miles@gnu.org> wrote: > Emacs has a rather small developer base, and most of the developers are > fairly busy with other things. A project with lots of developers that > are more intensely involved in development is naturally going to be more > reponsive. I don't think there's anything in Emacs that makes its developers inherently more "busy with other things", other than, perhaps, age. And then we go back to Eric's points about the Emacs' project (relative) inability to attract young developers. > Certainly the tools make _some_ difference, but I think ESR is > drastically overestimating how much of one. I think Eric is perhaps overestimating, but OTOH many comments in this thread seem a bit underestimating to me. The truth is, we don't have a crystal ball, and neither does Eric; we won't know unless/until we try it. But he's right that other big projects seem to be doing better, from a responsiveness POV. Now, every time that issue has been brought to discussion, the answers have centered about Emacs having few developers... So back to the previous point. > [BTW, one thing I think _would_ be very handy, and easy to implement, > would be an IRC channel for Emacs developers, just for those random > questions you wanna get a quick answer to sometimes... There's #emacs on > irc.freenode.net, but it's more user-level.] Which goes to show how different people's priorities are. IRC would be to me the less interesting of Eric's proposals. But I know there are projects (Subversion, for example) which make use of it with good results. In case I'm not making myself clear, which is likely: I agree with most of what Eric has said in this thread. Even if we cannot now estimate whether switching tools would be a 5% or a 500% gain in productivity, there's the almost certainly that there would be a gain, and Emacs would make a step towards attracting more people. No, I don't have the numbers to back up that; it's a hunch, like most everything else said in this thread. But the simple fact that the discussion about bug tracking software, alternatives to CVS, etc. springs regularly in this list it's itself significant. Juanma ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 13:24 ` Miles Bader 2007-12-31 13:44 ` Alan Mackenzie 2007-12-31 15:14 ` Juanma Barranquero @ 2007-12-31 15:31 ` Eric S. Raymond 2 siblings, 0 replies; 258+ messages in thread From: Eric S. Raymond @ 2007-12-31 15:31 UTC (permalink / raw) To: Miles Bader; +Cc: Alan Mackenzie, emacs-devel, Eric S. Raymond Miles Bader <miles@gnu.org>: > I suspect that 90% of the difference in "responsiveness" between the two > projects has to do with the people (and numbers of people) involved, not > with the tools being used. I don't think those are separable -- I think Wesnoth has more developers in significant part *because* its tools are better. > Certainly the tools make _some_ difference, but I think ESR is > drastically overestimating how much of one. You may be right. But we won't know until we fix our toolset and see, and fixing our toolset would have important benefits even at our current scale. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 13:11 ` Alan Mackenzie 2007-12-31 13:24 ` Miles Bader @ 2007-12-31 15:25 ` Eric S. Raymond 2008-01-01 20:34 ` Alan Mackenzie 1 sibling, 1 reply; 258+ messages in thread From: Eric S. Raymond @ 2007-12-31 15:25 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Eric S. Raymond, emacs-devel Alan Mackenzie <acm@muc.de>: > Emacs is an atypical, very old, piece of free software. Wesnoth seems to > be about 5 years old. (I haven't found the repository online.) This has > some bearing on the differences in development processes. Indeed. It means we have a lot of history and bad habits to unburden ourselves of, and that's a problem Wesnoth does not have as acutely. (It dates from 2003.) > > a) That change can be referenced, through its Subversion revision ID. > > (So, for example, "Hey boucman, your r22615 broke linger mode!") > > Hopefully, people are considerate enough not to do this too often; > continually having to look somewhere else to get context is not nice. In fact that particular situation is rare. My point was that Wesnoth's communications tools help us correct such problems quickly. What a fighter pilot would call our "OODA loop" is very fast. > > b) That change can be backed out as a unit. > > That's fine if nearly all changes are independent. In Emacs, I think, > this is not the case. It's actually very useful even when changes are intertangled. For one thing, it makes isolating regressions via a bisection search practical. While this is theoretically possible under CVS, there is just enough friction to make it something people seldom or never actually do. > Such easy backing out could lead to problems. I find that the problems of easy backout are far outweighed by its benefits. As a recent example: my lieutenant on one of my other projects (GPSD) committed a change that broke our regression tests. It was a day and a half and about a dozen commits later when I noticed this. It matters that I was *immediately* able to back out both the bad commits with high confidence that I was not leaving the code in an inconsistent state. (And rap him on the knuckles, but that was a social act and not a technical one.) > > 2. My commit is also echoed to the IRC channel, where there are almost > > never fewer than three or four devs hanging out as they hack, chatting > > in real time. Review tends to happen instantly. > > What about fixes that are too big for instant review? Emacs has lots of > bugs (and often fixes ;-) that are barely tractable, so that the slower > pace of email seems a better fit. IRC functions as a kind of triage on such changes. If we can't resolve a problem in real time, we fall back to the mailing list. This happens much less often than I myself would have expected before I became used to this style. I'll admit, it did take me some adjustment to get used to. The Wesnoth devs are mostly kids who have grown up in a post-MTV world, used to constant multitasking. I just turned 50. When I first contemplated getting involved, about nine months ago now, I had to wrestle with some fear that (a) I would be distracted and losing focus all the time, and (b) worse, I might discover that I was simply too old and lacked the mental agility to keep up. The second, especially, would have been crushing. I had to screw up my courage to try doing things their way lest I discover myself to be inadequate. In fact, both fears proved groundless. Nowadays I routinely have an IRC client open in five tabs to three different projects, and it all just becomes part of my flow. I think it matters a lot that IRC chat is silent -- I absolutely can't imagine imagine maintaining concentration while multiplexing that many voice channels. And far from finding I can't keep up, I've discovered that I like the stimulation. I grok how the kids feel about this, because mailing-list-only projects have started to seem slow and boring to me, too. > I've no experience of IIRC. But doesn't this way of working mean > continually dancing from one thing to another? I don't do that very > well. See above. I myself was afraid I wouldn't be able to handle this. But I adapted, and now I feel really liberated by having done so. > The "hyperlinks" bit sounds like you have to look at 3 or 4 things > simultaneously to be able to synthesise a context. How does this working > style work for difficult problems? Same way it does for easy ones. The difference is that with older, slower workflows we had to absorb all those bits of context more or less serially and buffer them in our heads for relatively long periods of time. I don't have to do that as much now -- it's more about keeping track of where the context is and quickly swapping in the parts I need at any given time. > > Yet a third is that when we decide to do it, we can converge on a > > releasable state with almost absurd ease. Like, Ivanovic (our release > > manager) will announce "Point release scheduled this coming Wednesday" > > and everyone will pretty much flip into bug-stomping mode. The tracker > > bug list tends to shrink dramatically when this happens -- not only do > > we get prepared for release but *we know we've done so*. > > Eric, how well do you think this could work at all for Emacs? I'm going to stop waving my hands and run some numbers. According to sloccount, the C core of Emacs is just about twice the size of Wesnoth's C++. Assuming the usual quadratic rise in bug density with LOC, the equivalent release tempo would be three months. But I think that's an overestimate. Our devs are more capable, and a fair amount of the Emacs core is either effectively dead (like, say, the VMS support) or so stable that it never needs to be touched. Then there's the C vs. C++ difference. All in all, I think six weeks is a reasonable guess for where we'd end up. "But..." I hear you say "you're ignoring the Lisp!". Yes, I am -- and that's because one thing rather clear from the Changelogs and NEWS files is that the Lisp code is not where the long-term release blockers tend to pop up. > > More generally, development happens *fast*. I don't have to wait weeks > > to find out whether other devs think of an idea. Commonly I know > > within minutes. > > On emacs-devel, this takes hours, not weeks. At any given time, most > Emacs developers are either asleep or doing other things (like earning > their living). Doesn't this quick-fire style end up excluding lots of > hackers from participation? It doesn't seem to work that way in practice. Or, at least, I don't hear hackers bitching about not being involved in decisions. What the core devs (including me) seem to do is keep one eye on the project IRC channel more or less constantly while doing those other things. > > The Wesnoth devs are good but not exceptionally so, and we're weighed > > down by a crappy implementation language (C++). > > Yuck!! Indeed. I've had to become competent at it. This has been painful. > > Nevertheless our productivity, in terms of goals achieved per hour of > > work, is quite high. That's because our collaboration tools support > > everything we do without imposing noticeable process friction. This > > makes us dramatically more effective as individuals and as a group than > > we could possibly be without them. > > Might it also be because your code base is still young, clean and > flexible? It's an appealing theory, but...no. The Wesnoth code is not at all clean internally, and the Wesnoth devs themselves often bitch about its rigidity. There are two reasons for this. One is C++; enough said. The other is that the Wesnoth devs are, on average, somewhat less capable and a lot less experienced than Emacs's have been -- and their most serious weakness tends to be a very limited understanding of design for maintainability. The result, unfortunately, is that while the Wesnoth code is much younger than of Emacs, it has already achieved a comparable cruft level :-(. > > Lessons for the Emacs project? Hell, yes. But I'm not going to write > > that rant until y'all have had a little time to absorb this description > > of how things can be. > > I'll look forward to that! We'd all welcome a process for releasing > every few months rather than twice a decade. Yeah. That would be good. My worst-case estimate, with modern tools, would be a three-to-four month release cycle. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-31 15:25 ` Eric S. Raymond @ 2008-01-01 20:34 ` Alan Mackenzie 2008-01-01 20:57 ` Eric S. Raymond 0 siblings, 1 reply; 258+ messages in thread From: Alan Mackenzie @ 2008-01-01 20:34 UTC (permalink / raw) To: Eric S. Raymond; +Cc: emacs-devel Hi, Eric! On Mon, Dec 31, 2007 at 10:25:09AM -0500, Eric S. Raymond wrote: > Alan Mackenzie <acm@muc.de>: > > Emacs is an atypical, very old, piece of free software. Wesnoth seems to > > be about 5 years old. (I haven't found the repository online.) This has > > some bearing on the differences in development processes. > Indeed. It means we have a lot of history and bad habits to unburden > ourselves of, and that's a problem Wesnoth does not have as > acutely. (It dates from 2003.) [ .... ] > > What about fixes that are too big for instant review? Emacs has lots > > of bugs (and often fixes ;-) that are barely tractable, so that the > > slower pace of email seems a better fit. > IRC functions as a kind of triage on such changes. If we can't resolve > a problem in real time, we fall back to the mailing list. This happens > much less often than I myself would have expected before I became used > to this style. Again, how can the Emacs developers do this? Some of us live in North America, others in Europe, East Asia and New Zealand, possibly other places too. We're never all going to be on line at the same time. Surely this process would promote a minority clique who would be making all the decisions. > I'll admit, it did take me some adjustment to get used to. The Wesnoth > devs are mostly kids who have grown up in a post-MTV world, used to > constant multitasking. I just turned 50. Yes, it's frightening. I'll be 50 next month. > When I first contemplated getting involved, about nine months ago now, > I had to wrestle with some fear that (a) I would be distracted and > losing focus all the time, and (b) worse, I might discover that I was > simply too old and lacked the mental agility to keep up. > The second, especially, would have been crushing. I had to screw up my > courage to try doing things their way lest I discover myself to > be inadequate. I empathise with this, too. I anticipate it making me feel dizzy. > In fact, both fears proved groundless. Nowadays I routinely have an > IRC client open in five tabs to three different projects, and it all > just becomes part of my flow. I think it matters a lot that IRC chat > is silent -- I absolutely can't imagine imagine maintaining > concentration while multiplexing that many voice channels. For me, silence means _nothing_ flashing or moving on the screen (except, perhaps, a cursor), no garishness, {scroll,tool,menu} bars switched off, and absolutely nothing like a dialog boxes exploding in my face. [ .... ] > > Eric, how well do you think this could work at all for Emacs? > I'm going to stop waving my hands and run some numbers. According to > sloccount, the C core of Emacs is just about twice the size of > Wesnoth's C++. Assuming the usual quadratic rise in bug density with > LOC, the equivalent release tempo would be three months. > But I think that's an overestimate. Our devs are more capable, and a fair > amount of the Emacs core is either effectively dead (like, say, the VMS > support) or so stable that it never needs to be touched. Then there's > the C vs. C++ difference. > All in all, I think six weeks is a reasonable guess for where we'd end up. OK. So we'd be modifying our goal of "bug free, exhaustively tested at each major release". This might be good, might be bad. > "But..." I hear you say "you're ignoring the Lisp!". Yes, I am -- and > that's because one thing rather clear from the Changelogs and NEWS > files is that the Lisp code is not where the long-term release blockers > tend to pop up. Really? That surprises me, though I haven't ever really studied the status. > > > More generally, development happens *fast*. I don't have to wait weeks > > > to find out whether other devs think of an idea. Commonly I know > > > within minutes. > > On emacs-devel, this takes hours, not weeks. At any given time, most > > Emacs developers are either asleep or doing other things (like earning > > their living). Doesn't this quick-fire style end up excluding lots of > > hackers from participation? > It doesn't seem to work that way in practice. Or, at least, I don't > hear hackers bitching about not being involved in decisions. What the > core devs (including me) seem to do is keep one eye on the project IRC > channel more or less constantly while doing those other things. Do these hackers live in a narrow band of time zones? [ .... ] -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 20:34 ` Alan Mackenzie @ 2008-01-01 20:57 ` Eric S. Raymond 2008-01-02 9:53 ` Richard Stallman 0 siblings, 1 reply; 258+ messages in thread From: Eric S. Raymond @ 2008-01-01 20:57 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel Alan Mackenzie <acm@muc.de>: > > IRC functions as a kind of triage on such changes. If we can't resolve > > a problem in real time, we fall back to the mailing list. This happens > > much less often than I myself would have expected before I became used > > to this style. > > Again, how can the Emacs developers do this? Some of us live in North > America, others in Europe, East Asia and New Zealand, possibly other > places too. We're never all going to be on line at the same time. No, and that's true on the Battle For Wesnoth project, too. In particular, we have for some reason a large contingent of developers in Germany, including the release manager. But the project founder is West Coast US; I and a couple of the other most active senior devs are East Coast US. So we're spread from GMT-1 to GMT+8. It works out, though. We all monitor #wesnoth-dev constantly. Well, OK, my IRC client is often minimized, but the task-bar entry for it glows discreetly orange when Chatzilla sees my name mentioned. > Surely this process would promote a minority clique who would be making > all the decisions. You do gradually gain status by being available when you're needed. And you do lose influence when you're not around for a while. But there's no cliquishness about it -- all you have to do to have a place in the discussion is show up, really. I went from newbie to senior dev in about four months by (a) pitching in doing a lot of work, and (b) often being available because I was working late at night when the Germans were waking up and joining IRC for the day. After a while the Germans started feeling unwilling to make large decisions without having me in on the conversation and partly adapted themselves to *my* schedule. I think one of the tipping points there was when the release manager (not a native English-speaker) started always having me spell-check the release announcements before he shipped them. > For me, silence means _nothing_ flashing or moving on the screen (except, > perhaps, a cursor), no garishness, {scroll,tool,menu} bars switched off, > and absolutely nothing like a dialog boxes exploding in my face. Chatzilla is your friend, then -- no flashy bits. Avoid Xchat. > OK. So we'd be modifying our goal of "bug free, exhaustively tested at > each major release". This might be good, might be bad. More likely we'd relax our standards for point releases at the six-week marks and do maybe two or three major releases a year with careful testing. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-01 20:57 ` Eric S. Raymond @ 2008-01-02 9:53 ` Richard Stallman 2008-01-02 12:29 ` Eric S. Raymond 0 siblings, 1 reply; 258+ messages in thread From: Richard Stallman @ 2008-01-02 9:53 UTC (permalink / raw) To: esr; +Cc: acm, emacs-devel You do gradually gain status by being available when you're needed. And you do lose influence when you're not around for a while. But there's no cliquishness about it -- all you have to do to have a place in the discussion is show up, really. I'd prefer a culture in which status comes from being willing and able to do the hard jobs. It sounds like that is a reason to mainly stick to email. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 9:53 ` Richard Stallman @ 2008-01-02 12:29 ` Eric S. Raymond 2008-01-02 12:59 ` dhruva 0 siblings, 1 reply; 258+ messages in thread From: Eric S. Raymond @ 2008-01-02 12:29 UTC (permalink / raw) To: Richard Stallman; +Cc: acm, emacs-devel Richard Stallman <rms@gnu.org>: > You do gradually gain status by being available when you're needed. And > you do lose influence when you're not around for a while. But there's > no cliquishness about it -- all you have to do to have a place in the > discussion is show up, really. > > I'd prefer a culture in which status comes from being willing and > able to do the hard jobs. It sounds like that is a reason to mainly > stick to email. Did you miss the bit where I talked about going from n00b to senior dev in four months because I pitched in and did a lot of hard work? You can have a place in the discussion just by showing up. But you only develop authority by taking responsibility. That has not changed, nor is it likely to. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 12:29 ` Eric S. Raymond @ 2008-01-02 12:59 ` dhruva 2008-01-02 13:11 ` Miles Bader ` (3 more replies) 0 siblings, 4 replies; 258+ messages in thread From: dhruva @ 2008-01-02 12:59 UTC (permalink / raw) To: esr; +Cc: acm, Richard Stallman, emacs-devel Hi, Anyone pitching in for mercurial (hg)? It is available on all platforms on which PYTHON runs. It works on OpenVMS too (not that many people here would care). Has fewer external dependencies (git needs a POSIX shell) and hence easy to deploy on non-UNIX platforms. A link to the mercurial book: http://hgbook.red-bean.com/hgbook.pdf It is very much GIT like in its usage but IMHO, much more portable as it is implemented in PYTHON (just like elisp code works where ever emacs runs). with best regards, dhruva -- Contents reflect my personal views only! ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 12:59 ` dhruva @ 2008-01-02 13:11 ` Miles Bader 2008-01-02 13:17 ` Tassilo Horn ` (2 subsequent siblings) 3 siblings, 0 replies; 258+ messages in thread From: Miles Bader @ 2008-01-02 13:11 UTC (permalink / raw) To: dhruva; +Cc: esr, acm, Richard Stallman, emacs-devel dhruva <dhruvakm@gmail.com> writes: > It is very much GIT like in its usage but IMHO, much more portable as > it is implemented in PYTHON (just like elisp code works where ever > emacs runs). Hg is sort of like "git for dummies"... [A python dependency is _not_ an advantage IMHO...] -Miles -- `Life is a boundless sea of bitterness' ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 12:59 ` dhruva 2008-01-02 13:11 ` Miles Bader @ 2008-01-02 13:17 ` Tassilo Horn 2008-01-02 13:49 ` David Kastrup 2008-01-02 13:48 ` Werner LEMBERG 2008-01-02 14:50 ` Eric S. Raymond 3 siblings, 1 reply; 258+ messages in thread From: Tassilo Horn @ 2008-01-02 13:17 UTC (permalink / raw) To: emacs-devel dhruva <dhruvakm@gmail.com> writes: Hi, > Anyone pitching in for mercurial (hg)? Before everybody posts his favourite SCM I'd say we wait until Eric finished his comparison paper. Then we'll have all pros and cons side by side and choose whichever fits our needs best. Talking about portability, git does run on anything POSIX and there's a fork for Windows (without cygwin), which is merged into the main line right now. (Maybe its already finished.) Bye, Tassilo ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 13:17 ` Tassilo Horn @ 2008-01-02 13:49 ` David Kastrup 2008-01-04 5:28 ` Richard Stallman 0 siblings, 1 reply; 258+ messages in thread From: David Kastrup @ 2008-01-02 13:49 UTC (permalink / raw) To: emacs-devel Tassilo Horn <tassilo@member.fsf.org> writes: > dhruva <dhruvakm@gmail.com> writes: > >> Anyone pitching in for mercurial (hg)? > > Before everybody posts his favourite SCM I'd say we wait until Eric > finished his comparison paper. Then we'll have all pros and cons side > by side and choose whichever fits our needs best. > > Talking about portability, git does run on anything POSIX and there's > a fork for Windows (without cygwin), which is merged into the main > line right now. (Maybe its already finished.) Not yet, as far as I know. I am partial to git because it is fast, flexible and can keep up with the history of code fragments moving between files (not just renaming). However, its current state for Windows developers is painful. While I don't use Windows myself, I do consider this sort of a showstopper. But git is actively headed towards supporting Windows quite well, and I would not want to rush into a different SCM just because of the Windows support when it appears that the severity of Windows drawbacks will go away mostly in a not so distant future. -- David Kastrup ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 13:49 ` David Kastrup @ 2008-01-04 5:28 ` Richard Stallman 2008-01-04 7:03 ` John S. Yates, Jr. 0 siblings, 1 reply; 258+ messages in thread From: Richard Stallman @ 2008-01-04 5:28 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel However, its current state for Windows developers is painful. While I don't use Windows myself, I do consider this sort of a showstopper. It is GNU Project policy that nothing concerning Windows support should be considered a showstopper. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-04 5:28 ` Richard Stallman @ 2008-01-04 7:03 ` John S. Yates, Jr. 2008-01-05 14:29 ` Richard Stallman 0 siblings, 1 reply; 258+ messages in thread From: John S. Yates, Jr. @ 2008-01-04 7:03 UTC (permalink / raw) To: rms; +Cc: emacs-devel DAK> However, its current state for Windows developers is painful. While DAK> I don't use Windows myself, I do consider this sort of a showstopper. RMS> It is GNU Project policy that nothing concerning Windows support RMS> should be considered a showstopper. This feels like a knee-jerk reaction to the appearance of the terms Windows and showstopper in close proximity. David was referring to rolling out use of a new DVCS, not delivering a Gnu project release. The show being stopped was either the specific tool selection or the roll out schedule. Surely you do not believe that emacs developers on Windows boxes do nothing more than work in Windows-specific areas. Your statement could be interpreted as saying that not only would you offer the Windows world no quarter but furthermore that you could not care less about disenfranchising emacs contributors stuck working in Windows-based environments, often because of circumstances over which they have no control. Working on a Windows box is not equivalent to supporting proprietary software. Thoughtlessly obstructing the propagation of Gnu software into the Windows world or impeding Windows-based developers from contributing productively to Gnu projects would be difficult for me to understand. /john ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-04 7:03 ` John S. Yates, Jr. @ 2008-01-05 14:29 ` Richard Stallman 0 siblings, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-05 14:29 UTC (permalink / raw) To: John S. Yates, Jr.; +Cc: emacs-devel This feels like a knee-jerk reaction to the appearance of the terms Windows and showstopper in close proximity. David was referring to rolling out use of a new DVCS, not delivering a Gnu project release. The show being stopped was either the specific tool selection or the roll out schedule. Yes, I know. Surely you do not believe that emacs developers on Windows boxes do nothing more than work in Windows-specific areas. You are correct, I don't believe that. Your statement could be interpreted as saying that not only would you offer the Windows world no quarter but furthermore that you could not care less about disenfranchising emacs contributors Words such as "enfranchise" are inappropriate because they imply recognizing someone's entitlement. That's not what accepting contributions consists of. Thoughtlessly obstructing the propagation of Gnu software into the Windows world or impeding Windows-based developers from contributing productively to Gnu projects would be difficult for me to understand. Whatever tool we choose, and whatever drawbacks we choose in spite of, the choice will not be thoughtless. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 12:59 ` dhruva 2008-01-02 13:11 ` Miles Bader 2008-01-02 13:17 ` Tassilo Horn @ 2008-01-02 13:48 ` Werner LEMBERG 2008-01-02 13:56 ` dhruva ` (2 more replies) 2008-01-02 14:50 ` Eric S. Raymond 3 siblings, 3 replies; 258+ messages in thread From: Werner LEMBERG @ 2008-01-02 13:48 UTC (permalink / raw) To: dhruvakm; +Cc: esr, acm, rms, emacs-devel > Anyone pitching in for mercurial (hg)? It is available on all > platforms on which PYTHON runs. It works on OpenVMS too (not that > many people here would care). Has fewer external dependencies (git > needs a POSIX shell) and hence easy to deploy on non-UNIX platforms. What's the mercurial equivalent to gitk? Werner ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 13:48 ` Werner LEMBERG @ 2008-01-02 13:56 ` dhruva 2008-01-02 14:55 ` Eric S. Raymond 2008-01-03 1:13 ` Giorgos Keramidas 2 siblings, 0 replies; 258+ messages in thread From: dhruva @ 2008-01-02 13:56 UTC (permalink / raw) To: Werner LEMBERG; +Cc: esr, acm, rms, emacs-devel Hi, On Jan 2, 2008 7:18 PM, Werner LEMBERG <wl@gnu.org> wrote: > What's the mercurial equivalent to gitk? hgk (based on gitk) -dky -- Contents reflect my personal views only! ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 13:48 ` Werner LEMBERG 2008-01-02 13:56 ` dhruva @ 2008-01-02 14:55 ` Eric S. Raymond 2008-01-03 1:13 ` Giorgos Keramidas 2 siblings, 0 replies; 258+ messages in thread From: Eric S. Raymond @ 2008-01-02 14:55 UTC (permalink / raw) To: Werner LEMBERG; +Cc: emacs-devel, rms, acm Werner LEMBERG <wl@gnu.org>: > > Anyone pitching in for mercurial (hg)? It is available on all > > platforms on which PYTHON runs. It works on OpenVMS too (not that > > many people here would care). Has fewer external dependencies (git > > needs a POSIX shell) and hence easy to deploy on non-UNIX platforms. > > What's the mercurial equivalent to gitk? Try "hg view". Even the window layout is strikingly similar. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 13:48 ` Werner LEMBERG 2008-01-02 13:56 ` dhruva 2008-01-02 14:55 ` Eric S. Raymond @ 2008-01-03 1:13 ` Giorgos Keramidas 2 siblings, 0 replies; 258+ messages in thread From: Giorgos Keramidas @ 2008-01-03 1:13 UTC (permalink / raw) To: Werner LEMBERG; +Cc: esr, emacs-devel, rms, acm On 2008-01-02 14:48, Werner LEMBERG <wl@gnu.org> wrote: > > Anyone pitching in for mercurial (hg)? It is available on all > > platforms on which PYTHON runs. It works on OpenVMS too (not that > > many people here would care). Has fewer external dependencies (git > > needs a POSIX shell) and hence easy to deploy on non-UNIX platforms. > > What's the mercurial equivalent to gitk? hgview. http://lists.logilab.org/pipermail/announce/2007-February/000052.html A screenshot is also available at: http://www.logilab.org/3438 ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-02 12:59 ` dhruva ` (2 preceding siblings ...) 2008-01-02 13:48 ` Werner LEMBERG @ 2008-01-02 14:50 ` Eric S. Raymond 3 siblings, 0 replies; 258+ messages in thread From: Eric S. Raymond @ 2008-01-02 14:50 UTC (permalink / raw) To: dhruva; +Cc: acm, Richard Stallman, emacs-devel dhruva <dhruvakm@gmail.com>: > Anyone pitching in for mercurial (hg)? You mail probably crossed one from me in which I noted that I am leaning towards Mercurial for my personal use. It may well be that I end up recommending Mercurial for Emacs; in fact I think that's the most likely outcome of my research. But I am not yet prepared to make that or any other recommendation before finishing my survey. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2007-12-30 12:22 What a modern collaboration toolkit looks like Eric S. Raymond ` (3 preceding siblings ...) 2007-12-31 13:11 ` Alan Mackenzie @ 2008-01-19 17:45 ` Jari Aalto 2008-01-20 2:59 ` dhruva 2008-01-21 9:07 ` Richard Stallman 4 siblings, 2 replies; 258+ messages in thread From: Jari Aalto @ 2008-01-19 17:45 UTC (permalink / raw) To: emacs-devel; +Cc: jaalto * Sun 2007-12-30 Eric Raymond <esr@snark.thyrsus.com> gmane.emacs.devel * Message-Id: 20071230122217.3CA84830B9A@snark.thyrsus.com > > This is a typical modern open-source project. It's not even a > particularly large one -- no more than a dozen core devs, 58 > developers total. Here are the collaborative tools we use every day: > > * Source control with Subversion I saw discussion that a change from CVS to distributed version control is under consideration. To shed a little light to the DCVS scene, here is one of my presentations: http://www.cante.net/~jaalto/doc/version-control-systems.pdf Follow the small knobs "*" and underlined words to find out more information (URL links). SUMMARY The git seems to be overall winner. It's a clear choice for big projects. - Git: phase of development is staggering and in few years the UI/OS compatibility issues are past * The branching and merging "in place" (no separate directories) is thing that excells over any other VCS/DCVS. A Brilliant invention and simple to use. * Vibrant community: ask a question and you get instant answers to anything. * The weak point is UI: it is very complicated. Currently requires very steep learning curve even from users that have prior experience (CVS/SVN stc.) - Bzr seems to take second place. It has a long term progression path and support, very strict code quality and clearly defined development phases. * I estimate that it will improved in two years time to meet needs of almost any user. * Out of the box Central / semi-central / distributed support (much nicer than git's) * The best is UI: it's very smooth, uniform, logical and a CVS/SVN user is immediately at home with it. * Weak point: performance problems with big repositories with lot of old history. These will however be solved soon (1 year; during 2008). Despite the popularity that Hg has been chosen by "Big projects" like OpenJDK etc., I would not incline to recommended it. Reasons: Too slow release schedule, small dev team, unclear roadmap. My observation is based on: * Page 11: "DCVS Release Schedules" * Page 12: "Pace of Development (1)" * Page 13: "Pace of Development (2)" Jari NOTES -------------- VCS = Version Control System (software) git = Git http://git-scm.org bzr = Bazaar http://bazaar-vcs.org hg = Mercurial http://www.selenic.com/mercurial/ ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-19 17:45 ` Jari Aalto @ 2008-01-20 2:59 ` dhruva 2008-01-20 5:10 ` Miles Bader 2008-01-21 9:07 ` Richard Stallman 1 sibling, 1 reply; 258+ messages in thread From: dhruva @ 2008-01-20 2:59 UTC (permalink / raw) To: Jari Aalto, emacs-devel, jaalto Hello, I request you all to consider the deployment scenerio too and please do not ignore users/dev on M$. - git needs a bunch of unix tools and the cygwin bash shell. The user will have to start getting used to the unix way - git needs perl (on top of shell) - mercurial just needs python I personally find tools with large deployment dependancies a real problem as each component will keep getting fixes/updates. -dky On 1/19/08, Jari Aalto <jari.aalto@cante.net> wrote: > * Sun 2007-12-30 Eric Raymond <esr@snark.thyrsus.com> gmane.emacs.devel > * Message-Id: 20071230122217.3CA84830B9A@snark.thyrsus.com > > > > This is a typical modern open-source project. It's not even a > > particularly large one -- no more than a dozen core devs, 58 > > developers total. Here are the collaborative tools we use every day: > > > > * Source control with Subversion > > I saw discussion that a change from CVS to distributed version control > is under consideration. To shed a little light to the DCVS scene, here > is one of my presentations: > > http://www.cante.net/~jaalto/doc/version-control-systems.pdf > > Follow the small knobs "*" and underlined words to find out more > information (URL links). > > SUMMARY > > The git seems to be overall winner. It's a clear choice for big > projects. > > - Git: phase of development is staggering and in few years > the UI/OS compatibility issues are past > * The branching and merging "in place" (no separate directories) > is thing that excells over any other VCS/DCVS. A Brilliant invention > and simple to use. > * Vibrant community: ask a question and you get instant answers to > anything. > * The weak point is UI: it is very complicated. Currently > requires very steep learning curve even from users that > have prior experience (CVS/SVN stc.) > > - Bzr seems to take second place. It has a long term progression path > and support, very strict code quality and clearly defined > development phases. > * I estimate that it will improved in two years time to meet > needs of almost any user. > * Out of the box Central / semi-central / distributed support > (much nicer than git's) > * The best is UI: it's very smooth, uniform, logical and > a CVS/SVN user is immediately at home with it. > * Weak point: performance problems with big repositories with > lot of old history. These will however be solved soon (1 year; > during 2008). > > Despite the popularity that Hg has been chosen by "Big projects" like > OpenJDK etc., I would not incline to recommended it. Reasons: Too slow > release schedule, small dev team, unclear roadmap. My observation is > based on: > > * Page 11: "DCVS Release Schedules" > * Page 12: "Pace of Development (1)" > * Page 13: "Pace of Development (2)" > > Jari > > NOTES > -------------- > > VCS = Version Control System (software) > git = Git http://git-scm.org > bzr = Bazaar http://bazaar-vcs.org > hg = Mercurial http://www.selenic.com/mercurial/ > > > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-devel > -- Sent from Gmail for mobile | mobile.google.com Contents reflect my personal views only! ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-20 2:59 ` dhruva @ 2008-01-20 5:10 ` Miles Bader 2008-01-20 5:36 ` Juanma Barranquero 0 siblings, 1 reply; 258+ messages in thread From: Miles Bader @ 2008-01-20 5:10 UTC (permalink / raw) To: dhruva; +Cc: jaalto, emacs-devel, Jari Aalto dhruva <dhruvakm@gmail.com> writes: > I request you all to consider the deployment scenerio too and please > do not ignore users/dev on M$. They are not ignored, merely treated as a secondary concern. cygwin seems like a fine solution for supporting developers on windows. -Miles -- `Suppose Korea goes to the World Cup final against Japan and wins,' Moon said. `All the past could be forgiven.' [NYT] ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-20 5:10 ` Miles Bader @ 2008-01-20 5:36 ` Juanma Barranquero 2008-01-20 6:03 ` Miles Bader 0 siblings, 1 reply; 258+ messages in thread From: Juanma Barranquero @ 2008-01-20 5:36 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel On Jan 20, 2008 6:10 AM, Miles Bader <miles@gnu.org> wrote: > cygwin seems like a fine solution for supporting developers on windows. I doubt Cygwin can be "a fine solution" for anything, but that's just me. However, as someone already said, there's MSYS/MinGW port of git in the works. It lacks some things (Subversion importing, daemon, most things related to e-mail...), but it is quite useable. That's not to say that git it is preferable over mercurial, however. Let's first read Eric's article. Juanma ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-20 5:36 ` Juanma Barranquero @ 2008-01-20 6:03 ` Miles Bader 2008-01-20 19:28 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 258+ messages in thread From: Miles Bader @ 2008-01-20 6:03 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel "Juanma Barranquero" <lekktu@gmail.com> writes: > I doubt Cygwin can be "a fine solution" for anything, but that's just me. There seem to be a fair number of windows users who have some sort of gripe with cygwin, but I've never quite understood what it is... Whenever I try cygwin, things just work, and installing it seems completely painless. > However, as someone already said, there's MSYS/MinGW port of git in > the works. It lacks some things (Subversion importing, daemon, most > things related to e-mail...), but it is quite useable. Yes, obviously in the long run, the msys git port will probably be preferable to the majority of developers. What you say above seems to indicate it's further along than I realized. > That's not to say that git it is preferable over mercurial, however. > Let's first read Eric's article. When Eric finishes his "article", it will be something to consider, but please don't give the impression that it will be some kind of definitive statement on the issue. Eric, besides having rather obvious lack of experience with many of these systems, has already shown clear biases. It's very hard for even somebody trying hard to be objective to do a good job of such a comparison. -Miles -- I'd rather be consing. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-20 6:03 ` Miles Bader @ 2008-01-20 19:28 ` Eli Zaretskii 2008-01-20 20:42 ` Juanma Barranquero 2008-01-20 20:17 ` Juanma Barranquero 2008-01-20 20:28 ` Juanma Barranquero 2 siblings, 1 reply; 258+ messages in thread From: Eli Zaretskii @ 2008-01-20 19:28 UTC (permalink / raw) To: Miles Bader; +Cc: lekktu, emacs-devel > From: Miles Bader <miles@gnu.org> > Date: Sun, 20 Jan 2008 15:03:50 +0900 > Cc: emacs-devel@gnu.org > > "Juanma Barranquero" <lekktu@gmail.com> writes: > > I doubt Cygwin can be "a fine solution" for anything, but that's just me. > > There seem to be a fair number of windows users who have some sort of > gripe with cygwin, but I've never quite understood what it > is... The gripe is threefold: . You cannot install a single Cygwin package seamlessly, without pulling in a whole bunch of other packages (which could potentially conflict with whatever else you have on your machine -- a hassle, since Cygwin is subtly incompatible with non-Cygwin programs). . There can be only one Cygwin DLL on any given system. This is a hassle: e.g., it practically requires that you always upgrade all your Cygwin packages whenever a new version is uploaded. . Compared to native ports, Cygwin is slow. The first two problems mean in practice that Cygwin is a catholic marriage, unless one has lots of time to tinker with their system. There: now you've heard it. > Yes, obviously in the long run, the msys git port will probably be > preferable to the majority of developers. What you say above seems to > indicate it's further along than I realized. MSYS is just a fork of Cygwin, and as such, shares most of its problems mentioned above. Its primary goal was to provide a _build_ environment for native MinGW ports, not a platform to produce ports used outside of the build environment for their own good. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-20 19:28 ` Eli Zaretskii @ 2008-01-20 20:42 ` Juanma Barranquero 0 siblings, 0 replies; 258+ messages in thread From: Juanma Barranquero @ 2008-01-20 20:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, Miles Bader On Jan 20, 2008 8:28 PM, Eli Zaretskii <eliz@gnu.org> wrote: > MSYS is just a fork of Cygwin, and as such, shares most of its > problems mentioned above. msysGit comes with tools from MSYS or built with MSYS (bash, bzip2, cat, perl, etc.), but the git executables do not depend on msys-1.0.dll; I think they are normal MinGW executables. Juanma ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-20 6:03 ` Miles Bader 2008-01-20 19:28 ` Eli Zaretskii @ 2008-01-20 20:17 ` Juanma Barranquero 2008-01-20 20:28 ` Juanma Barranquero 2 siblings, 0 replies; 258+ messages in thread From: Juanma Barranquero @ 2008-01-20 20:17 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel On Jan 20, 2008 7:03 AM, Miles Bader <miles@gnu.org> wrote: > Yes, obviously in the long run, the msys git port will probably be > preferable to the majority of developers. What you say above seems to > indicate it's further along than I realized. > > > That's not to say that git it is preferable over mercurial, however. > > Let's first read Eric's article. > > When Eric finishes his "article", it will be something to consider, but > please don't give the impression that it will be some kind of definitive > statement on the issue. Eric, besides having rather obvious lack of > experience with many of these systems, has already shown clear biases. > It's very hard for even somebody trying hard to be objective to do a > good job of such a comparison. > > -Miles > > -- > I'd rather be consing. > -- Juanma ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-20 6:03 ` Miles Bader 2008-01-20 19:28 ` Eli Zaretskii 2008-01-20 20:17 ` Juanma Barranquero @ 2008-01-20 20:28 ` Juanma Barranquero 2008-01-21 2:11 ` Miles Bader 2 siblings, 1 reply; 258+ messages in thread From: Juanma Barranquero @ 2008-01-20 20:28 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel [Sorry for the previous empty message] > Yes, obviously in the long run, the msys git port will probably be > preferable to the majority of developers. What you say above seems to > indicate it's further along than I realized. Well. Most basic things work: you can clone, commit, rebase, pull, push, handle branches, etc. The basic workflow is there. What I tried to say is not that git on Windows is near completion, but that, were Emacs to switch to git, the msysGit functionality would be enough for Windows developers not to be left in the cold (that was my primary worry; whether we switch to git or mercurial or bazaar or monotone, I don't particularly care). > When Eric finishes his "article", it will be something to consider, but > please don't give the impression that it will be some kind of definitive > statement on the issue. Eric, besides having rather obvious lack of > experience with many of these systems, has already shown clear biases. I wasn't trying to give that impression. But as obviously Eric is investing effort both to show better ways for the Emacs project (whether what he points is better or not is open to discussion, but it would be unfair to negate that he's trying to Do Good) and to evaluate alternatives, I think it would be polite to at least hear him. Of course he's biased. Aren't we all? > It's very hard for even somebody trying hard to be objective to do a > good job of such a comparison. I don't think we need a good general comparison; more like a good comparison from people who has a working knowledge of the dVCS tools and, most important, knows about Emacs development. Juanma ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-20 20:28 ` Juanma Barranquero @ 2008-01-21 2:11 ` Miles Bader 2008-01-21 2:38 ` Karl Fogel ` (2 more replies) 0 siblings, 3 replies; 258+ messages in thread From: Miles Bader @ 2008-01-21 2:11 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel "Juanma Barranquero" <lekktu@gmail.com> writes: >> It's very hard for even somebody trying hard to be objective to do a >> good job of such a comparison. > > I don't think we need a good general comparison; more like a good > comparison from people who has a working knowledge of the dVCS tools > and, most important, knows about Emacs development. Many of the regular developers on this list appear to have a great deal more experience with both (dVCS tools and Emacs development) than Eric does... -Miles -- Road, n. A strip of land along which one may pass from where it is too tiresome to be to where it is futile to go. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 2:11 ` Miles Bader @ 2008-01-21 2:38 ` Karl Fogel 2008-01-21 2:49 ` Miles Bader 2008-01-21 2:41 ` Juanma Barranquero 2008-01-21 3:01 ` Nick Roberts 2 siblings, 1 reply; 258+ messages in thread From: Karl Fogel @ 2008-01-21 2:38 UTC (permalink / raw) To: Miles Bader; +Cc: Juanma Barranquero, emacs-devel Miles Bader <miles.bader@necel.com> writes: > "Juanma Barranquero" <lekktu@gmail.com> writes: >>> It's very hard for even somebody trying hard to be objective to do a >>> good job of such a comparison. >> >> I don't think we need a good general comparison; more like a good >> comparison from people who has a working knowledge of the dVCS tools >> and, most important, knows about Emacs development. > > Many of the regular developers on this list appear to have a great deal > more experience with both (dVCS tools and Emacs development) than Eric > does... But Eric has stepped forward to actually do the comparison work here. (He also has enough experience in both fields for this purpose, even if there are people here who have more with one field, the other, or both.) I'm looking forward to his comparison and recommendations. I'd also look forward to yours, of course. -Karl ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 2:38 ` Karl Fogel @ 2008-01-21 2:49 ` Miles Bader 2008-01-21 3:06 ` Nick Roberts 2008-01-21 3:16 ` Glenn Morris 0 siblings, 2 replies; 258+ messages in thread From: Miles Bader @ 2008-01-21 2:49 UTC (permalink / raw) To: Karl Fogel; +Cc: Juanma Barranquero, emacs-devel Karl Fogel <kfogel@red-bean.com> writes: >> Many of the regular developers on this list appear to have a great deal >> more experience with both (dVCS tools and Emacs development) than Eric >> does... > > But Eric has stepped forward to actually do the comparison work here. Certainly his comparison will be welcome input, and perhaps a good starting point for more substantive discussion. -Miles -- `The suburb is an obsolete and contradictory form of human settlement' ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 2:49 ` Miles Bader @ 2008-01-21 3:06 ` Nick Roberts 2008-01-21 3:17 ` Miles Bader 2008-01-21 3:26 ` Stephen J. Turnbull 2008-01-21 3:16 ` Glenn Morris 1 sibling, 2 replies; 258+ messages in thread From: Nick Roberts @ 2008-01-21 3:06 UTC (permalink / raw) To: Miles Bader; +Cc: Karl Fogel, Juanma Barranquero, emacs-devel > Certainly his comparison will be welcome input, and perhaps a good > starting point for more substantive discussion. Starting point? More substantive? Entire version control systems have probably been written in less time than we've spent discussing them. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 3:06 ` Nick Roberts @ 2008-01-21 3:17 ` Miles Bader 2008-01-21 3:26 ` Stephen J. Turnbull 1 sibling, 0 replies; 258+ messages in thread From: Miles Bader @ 2008-01-21 3:17 UTC (permalink / raw) To: Nick Roberts; +Cc: Karl Fogel, Juanma Barranquero, emacs-devel Nick Roberts <nickrob@snap.net.nz> writes: > > Certainly his comparison will be welcome input, and perhaps a good > > starting point for more substantive discussion. > > Starting point? More substantive? Entire version control systems have > probably been written in less time than we've spent discussing them. Hey, if I was in control, we would have switched loooooong ago. Certainly there's been no lack of people advocating change. In any case, what choice do we have? Currently there seem to be three options: 1) We don't want for Eric's report, and discuss what to do without it. 2) We wait for the report, and use it as starting-point to discuss what to do. 3) We wait for the report, and just accept whatever conclusions it comes to, without discussion. Option (3) is clearly unacceptable. I personally feel there's enough expertise on this list to make (1) viable, but as others have expressed a desire to see what Eric says, and as a concise summary of the issues might help those who are unfamiliar with them, (2) seems like the best option. -Miles -- Laughter, n. An interior convulsion, producing a distortion of the features and accompanied by inarticulate noises. It is infectious and, though intermittent, incurable. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 3:06 ` Nick Roberts 2008-01-21 3:17 ` Miles Bader @ 2008-01-21 3:26 ` Stephen J. Turnbull 1 sibling, 0 replies; 258+ messages in thread From: Stephen J. Turnbull @ 2008-01-21 3:26 UTC (permalink / raw) To: Nick Roberts; +Cc: Karl Fogel, Juanma Barranquero, emacs-devel, Miles Bader Nick Roberts writes: > Starting point? More substantive? Entire version control systems have > probably been written in less time than we've spent discussing them. One of the few actual facts confirmed on Eric's UVC-Reviewers list is that indeed git was started on April 3 2005 and was (experimentally) hosting the Linux kernel developers project on April 13th, 10 days later. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 2:49 ` Miles Bader 2008-01-21 3:06 ` Nick Roberts @ 2008-01-21 3:16 ` Glenn Morris 2008-01-21 4:11 ` Nick Roberts 2008-01-21 10:00 ` Thien-Thi Nguyen 1 sibling, 2 replies; 258+ messages in thread From: Glenn Morris @ 2008-01-21 3:16 UTC (permalink / raw) To: emacs-devel <rant> I'm thoroughly fed up with this subject. Is anyone trying to tell me, that switching to some hip new version control system is going to make people start applying the patches that currently sit around in this mailing list for weeks? Or that when there is a shiny new bug tracker, people will suddenly start fixing all the bugs that get reported? I actually do think a bug tracker will be useful; I just think the problems of Emacs development lie in other places rather than the tools it uses. I don't care about the version control system. For me, the problems can be summed up in the fact that the number of people willing to write emails (and yes, that includes this one) about what should be done vastly outweighs the number of people willing to actually do anything. I was trying not to comment on this pointless thread, but I've failed. </rant> ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 3:16 ` Glenn Morris @ 2008-01-21 4:11 ` Nick Roberts 2008-01-21 10:00 ` Thien-Thi Nguyen 1 sibling, 0 replies; 258+ messages in thread From: Nick Roberts @ 2008-01-21 4:11 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel > Is anyone trying to tell me, that switching to some hip new version > control system is going to make people start applying the patches that > currently sit around in this mailing list for weeks? With GDB, developers who submit many patches are generally given write access. Those who only occasionally submit patches have their patch committed by the maintainer approving it. So IMHO Tom Tromey, Ken Mannheimer etc should have write access and others should be able to approve a patch. > Or that when there is a shiny new bug tracker, people will suddenly > start fixing all the bugs that get reported? They don't get fixed but they become more traceable. My recent bug report about vc-dired wouldn't get lost and it could be marked as a duplicate or related to the report Alexandru Harsanyi made about vc-workfile-unchanged-p in mid December 2007. ESR appears to have gone now, but with a tracker he could review the bugs listed under VC when he returns and might choose to fix any that caught his eye. It's just unfortunate that RMS sees a bug list as preventing a release rather than a database for recording new bugs and reviewing existing ones. > I actually do think a bug tracker will be useful; I just think the > problems of Emacs development lie in other places rather than the > tools it uses. They're separate issues, let's not blur them. > I don't care about the version control system. I think there could also be benefits here with merging branches, changesets, moving files etc. but it clearly also isn't a silver bullet. > For me, the problems can be summed up in the fact that the number of > people willing to write emails (and yes, that includes this one) about > what should be done vastly outweighs the number of people willing to > actually do anything. > > I was trying not to comment on this pointless thread, but I've failed. It's been unproductive but probably not pointless. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 3:16 ` Glenn Morris 2008-01-21 4:11 ` Nick Roberts @ 2008-01-21 10:00 ` Thien-Thi Nguyen 1 sibling, 0 replies; 258+ messages in thread From: Thien-Thi Nguyen @ 2008-01-21 10:00 UTC (permalink / raw) To: emacs-devel () Glenn Morris <rgm@gnu.org> () Sun, 20 Jan 2008 22:16:05 -0500 Is anyone trying to tell me, that switching to some hip new version control system is going to make people start applying the patches that currently sit around in this mailing list for weeks? Although i haven't in the past, i would be willing to tell you that, and will take time to explain why, now: Emacs hacking requires thought to "DTRT", which is inhibiting to me because experience leads me to ponder (mostly enjoyably, but more germainely, always lengthily) on the history of the context of that acronym as uttered by a specific person, to avoid getting burned by misunderstanding. When rms sez "DTRT", i work hard to disambiguate its meaning from when jrhacker sez "DTRT". Perhaps others find it easier; i cannot speak for others. A distributed version control system (my bias is towards git at the moment) separates DTRT_process from DTRT_code up to the time of publishing the change. The effect is that i can parallelize my pondering to some (Amdahl-limited ;--) extent, and thus check in things faster. Now let's turn from commit 0 in a series, to commit N. Why is there a commit N? Because commit 0 was problematic in some way, even though supreme effort was (presumably) expended to DTRT. i.e, commit 0 did NOT DTRT; i make mistakes, i misunderstand. A distributed version control system would mitigate this by letting me do commit 0 locally, iterating N times until my practice matches what is considered to be TRT. This is basically a restatement of the parallelized pondering paragraph above, w/ s/understanding/practice/g. "But", you may be thinking, "what does that have to do w/ patches that have been sitting around for weeks?" Well, i have write privs and i am happy to check in code that DTRT from those that do not have write privs. But how do i know that code DTRT? How do i know its author has iterated enough so that the understanding/practice reflected therein has the quality of commit N and not quality of commit 0? One answer to these questions starts w/ "It's none of your business; why do you care?; your part is merely secretarial." To which i can only say: sorry, i do care, and will ignore arguments in that vein. Another answer is: "Learn the code; use the opportunity of its passing through your brain to expand your expertise -- in that way you will recognize if it DTRT." To which i say: agreed mostly, but not fully. I can expand my understanding of such code, per se, but w/o access to its history, the understanding is illusory and incomplete. There is a chance that i have merely stumbled upon a superficial outcropping of deeper (more interesting) issues, that my grokking is mere luck, and most dangerously, that the overlapped (between myself and the code's author) grokking is transitory. "Looks good because of X", thinks ttn. "*IS* good because of Y", thinks its author. Patch applied. Fast-forward two months; ttn hacks on the code to support X better, breaking Y. Lose. IMHO expanding my expertise is best done by building on the expertise of others. A distributed version control system combined w/ people's disinhibition of exposing their mistakes allows me to more quickly grok the thought that went into the presented patch as well as the code it changes, align my thoughts w/ it, iterate w/ the author as necessary to achieve quality of commit N, and apply it. In the end, my spewing here might seem like an indictment of DTRT. Perhaps. But i tend to think otherwise: i think "DTRT" ethos needs to grow up and leave the nest. This involves two things: supporting a phase separation of D and TRT, and expansion of TRT to not only accept mistakes, but to actively support archeological non-punitive reflection on the actions that surround them. thi ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 2:11 ` Miles Bader 2008-01-21 2:38 ` Karl Fogel @ 2008-01-21 2:41 ` Juanma Barranquero 2008-01-21 3:01 ` Nick Roberts 2 siblings, 0 replies; 258+ messages in thread From: Juanma Barranquero @ 2008-01-21 2:41 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel On Jan 21, 2008 3:11 AM, Miles Bader <miles.bader@necel.com> wrote: > Many of the regular developers on this list appear to have a great deal > more experience with both (dVCS tools and Emacs development) than Eric > does... Yes. Perhaps that's why Eric asked for collaborators and reviewers for his paper... But, really. I haven't said we should take Eric's word as gospel [1]. I've just said we should wait and read what he writes. It seems common courtesy, as it is him who brought the issue of Emacs development tools back from oblivion (this time), and the only one who seems to be investing time. Juanma [1] I don't usually agree with 10% of what Eric says. The last time I read something by him I could fully enjoy was "A Guide to the Mazes of Menace", the Nethack guidebook. But that does not mean I don't appreciate the energy he's throwing at this. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 2:11 ` Miles Bader 2008-01-21 2:38 ` Karl Fogel 2008-01-21 2:41 ` Juanma Barranquero @ 2008-01-21 3:01 ` Nick Roberts 2 siblings, 0 replies; 258+ messages in thread From: Nick Roberts @ 2008-01-21 3:01 UTC (permalink / raw) To: Miles Bader; +Cc: Juanma Barranquero, emacs-devel > Many of the regular developers on this list appear to have a great deal > more experience with both (dVCS tools and Emacs development) than Eric > does... Collectively, perhaps. Most seemed to share their point of view from the system(s) with which they were familiar. I can see that placing the entire revision history of Emacs in a new VCS is a major undertaking that is not to be taken lightly. Choosing a bug tracker, in comparison, is trivial: if we don't like it, we stop using it. How about just approaching that task first? RMS has said: debbugs looks plausible, but what I would really like is for someone to try using the various possible bug trackers, limiting himself to email, and report on how well each one works in that mode. It looks unlikely that anyone is willing to be quite so self-sacrificing. Is it possible for someone to set up a Debian machine that is connected to the Internet with debbugs and just see what happens? Or are we just going to spend the rest of 2008, 2009,... talking about it? -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-19 17:45 ` Jari Aalto 2008-01-20 2:59 ` dhruva @ 2008-01-21 9:07 ` Richard Stallman 2008-01-21 15:51 ` Dan Nicolaescu 2008-01-24 14:43 ` Mark A. Hershberger 1 sibling, 2 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-21 9:07 UTC (permalink / raw) To: Jari Aalto; +Cc: jaalto, emacs-devel Git: * The weak point is UI: it is very complicated. Currently requires very steep learning curve even from users that have prior experience (CVS/SVN stc.) Does VC in Emacs overcome that problem? - Bzr seems to take second place. It has a long term progression path and support, very strict code quality and clearly defined development phases. BZR may become a GNU package, which would be a reason to prefer it. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 9:07 ` Richard Stallman @ 2008-01-21 15:51 ` Dan Nicolaescu 2008-01-21 17:37 ` Miles Bader 2008-01-24 14:43 ` Mark A. Hershberger 1 sibling, 1 reply; 258+ messages in thread From: Dan Nicolaescu @ 2008-01-21 15:51 UTC (permalink / raw) To: rms; +Cc: jaalto, emacs-devel, Jari Aalto Richard Stallman <rms@gnu.org> writes: > Git: > > * The weak point is UI: it is very complicated. Currently > requires very steep learning curve even from users that > have prior experience (CVS/SVN stc.) > > Does VC in Emacs overcome that problem? It partially does, there are (BIG) missing pieces in the vc-git implementation: vc-update and branching are not implemented. And the UI for those 2 things is not good at all in Git. (The underlying functionality works very well, but it is quite hard to use if you don't have a thorough understanding on how Git works inside...) For vc-update: none of vc-git, vc-bzr and vc-hg implement it. vc-update needs work in order to support these systems properly, they want to merge on a whole project basis instead of file basis as vc-update currently does. > - Bzr seems to take second place. It has a long term progression path > and support, very strict code quality and clearly defined > development phases. > > BZR may become a GNU package, which would be a reason to prefer it. In the past surveys that I've seen Bzr was shown to be much slower compared with Git and Mercurial and take much more disk space. Not sure if that changed. BTW, Mercurial was too easily dismissed for not very serious reasons in the message you are replying to. It is used in a few very large projects, it still developed and it works very well. Hope this helps. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 15:51 ` Dan Nicolaescu @ 2008-01-21 17:37 ` Miles Bader 2008-01-21 17:53 ` Tom Tromey 2008-01-22 0:33 ` Dan Nicolaescu 0 siblings, 2 replies; 258+ messages in thread From: Miles Bader @ 2008-01-21 17:37 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Jari Aalto, jaalto, rms, emacs-devel Dan Nicolaescu <dann@ics.uci.edu> writes: > It partially does, there are (BIG) missing pieces in the vc-git > implementation: vc-update and branching are not implemented. > > For vc-update: none of vc-git, vc-bzr and vc-hg implement it. vc-update > needs work in order to support these systems properly, they want to > merge on a whole project basis instead of file basis as vc-update > currently does. Of course part of the problem is that vc-update seems like a hopelessly antiquated interface -- who wants to do merging on a file-by-file basis?! > And the UI for those 2 things is not good at all in Git. > (The underlying functionality works very well, but it is quite hard to > use if you don't have a thorough understanding on how Git works > inside...) What do you mean? [There are confusing things in git, but that hardly seems one of them...] -Miles -- `To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 17:37 ` Miles Bader @ 2008-01-21 17:53 ` Tom Tromey 2008-01-21 20:06 ` Stefan Monnier 2008-01-22 0:33 ` Dan Nicolaescu 1 sibling, 1 reply; 258+ messages in thread From: Tom Tromey @ 2008-01-21 17:53 UTC (permalink / raw) To: Miles Bader; +Cc: jaalto, Dan Nicolaescu, emacs-devel, rms, Jari Aalto >>>>> "Miles" == Miles Bader <miles@gnu.org> writes: Miles> Of course part of the problem is that vc-update seems like a hopelessly Miles> antiquated interface -- who wants to do merging on a file-by-file basis?! Yeah... for vc-status I think we will need a new 'update' back end function. Also I think we will need a "conflict" state. Tom ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 17:53 ` Tom Tromey @ 2008-01-21 20:06 ` Stefan Monnier 2008-01-21 19:50 ` Tom Tromey 0 siblings, 1 reply; 258+ messages in thread From: Stefan Monnier @ 2008-01-21 20:06 UTC (permalink / raw) To: Tom Tromey Cc: rms, emacs-devel, Dan Nicolaescu, Jari Aalto, jaalto, Miles Bader Miles> Of course part of the problem is that vc-update seems like a hopelessly Miles> antiquated interface -- who wants to do merging on a file-by-file basis?! > Yeah... for vc-status I think we will need a new 'update' back end Sounds right. > function. Also I think we will need a "conflict" state. Be careful with this one: some backends allow commits with conflicts (for later resolution). And for many operations, it doesn't matter if a file is locally modified or with a conflict, so in many ways "conflict" is a sub-state of "locally modified". Stefan ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 20:06 ` Stefan Monnier @ 2008-01-21 19:50 ` Tom Tromey 0 siblings, 0 replies; 258+ messages in thread From: Tom Tromey @ 2008-01-21 19:50 UTC (permalink / raw) To: Stefan Monnier Cc: rms, emacs-devel, Dan Nicolaescu, Jari Aalto, jaalto, Miles Bader >>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes: >> function. Also I think we will need a "conflict" state. Stefan> Be careful with this one: some backends allow commits with conflicts Stefan> (for later resolution). And for many operations, it doesn't matter if Stefan> a file is locally modified or with a conflict, so in many ways Stefan> "conflict" is a sub-state of "locally modified". Thanks. FWIW I didn't have any clue what particular semantics "conflict" should imply. I just think that, like pcl-cvs, it is useful to show this as a separate state in a vc-status buffer. Tom ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 17:37 ` Miles Bader 2008-01-21 17:53 ` Tom Tromey @ 2008-01-22 0:33 ` Dan Nicolaescu 1 sibling, 0 replies; 258+ messages in thread From: Dan Nicolaescu @ 2008-01-22 0:33 UTC (permalink / raw) To: Miles Bader; +Cc: jaalto, emacs-devel, rms, Jari Aalto Miles Bader <miles@gnu.org> writes: > Dan Nicolaescu <dann@ics.uci.edu> writes: > > It partially does, there are (BIG) missing pieces in the vc-git > > implementation: vc-update and branching are not implemented. > > > > For vc-update: none of vc-git, vc-bzr and vc-hg implement it. vc-update > > needs work in order to support these systems properly, they want to > > merge on a whole project basis instead of file basis as vc-update > > currently does. > > Of course part of the problem is that vc-update seems like a hopelessly > antiquated interface That was my point. This has been discussed a few times on the list, and I recently added it to the TODO list in vc.el. If anyone wants to volunteer and sit down and do it, it would be great. > > And the UI for those 2 things is not good at all in Git. > > (The underlying functionality works very well, but it is quite hard to > > use if you don't have a thorough understanding on how Git works > > inside...) > > What do you mean? [There are confusing things in git, but that hardly > seems one of them...] checkout vs checkout --track pull, fetch and the 50 options that each has. But I doubt that this is the right place to discuss these things. BTW, if anyone wants to see the difference in UI between git and Mercurial/Bzr, just look at the commands that are run to implement the VC interface in vc-{git,hg,bzr}.el. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-21 9:07 ` Richard Stallman 2008-01-21 15:51 ` Dan Nicolaescu @ 2008-01-24 14:43 ` Mark A. Hershberger 2008-01-24 15:00 ` Juanma Barranquero 1 sibling, 1 reply; 258+ messages in thread From: Mark A. Hershberger @ 2008-01-24 14:43 UTC (permalink / raw) To: emacs-devel; +Cc: Richard M. Stallman Richard Stallman <rms@gnu.org> writes: > - Bzr seems to take second place. It has a long term progression path > and support, very strict code quality and clearly defined > development phases. > > BZR may become a GNU package, which would be a reason to prefer it. Another reason to prefer it: stand-alone bzr binaries are available and work *now* in Windows. I've used bzr to do some work on a Windows port of the iHRIS system I'm working on. -- http://hexmode.com/ GPG Fingerprint: 7E15 362D A32C DFAB E4D2 B37A 735E F10A 2DFC BFF5 Ideas create idols; only wonder leads to knowing. -- St. Gregory of Nyssa ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-24 14:43 ` Mark A. Hershberger @ 2008-01-24 15:00 ` Juanma Barranquero 2008-01-24 15:34 ` dhruva 0 siblings, 1 reply; 258+ messages in thread From: Juanma Barranquero @ 2008-01-24 15:00 UTC (permalink / raw) To: Mark A. Hershberger; +Cc: emacs-devel On Jan 24, 2008 3:43 PM, Mark A. Hershberger <mah@everybody.org> wrote: > Another reason to prefer it: stand-alone bzr binaries are available and > work *now* in Windows. That's also true of mercurial, monotone, darcs and git, depending of how you do define "work now". Juanma ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-24 15:00 ` Juanma Barranquero @ 2008-01-24 15:34 ` dhruva 2008-01-24 19:52 ` Stephen J. Turnbull 0 siblings, 1 reply; 258+ messages in thread From: dhruva @ 2008-01-24 15:34 UTC (permalink / raw) To: Juanma Barranquero, Mark A. Hershberger, emacs-devel Hi, I would consider the ability to convert to other repository formats as important too. Whatever VCS gets adopted must not lose any history data and have enough metadata to be able to convert to other VCS formats. Though I am biased towards mercurial, there is one git feature I consider very good. Ability to run a git server for existing cvs clients. Though this might be contradictory to dVCS concepts (not too sure though) -dky On 1/24/08, Juanma Barranquero <lekktu@gmail.com> wrote: > On Jan 24, 2008 3:43 PM, Mark A. Hershberger <mah@everybody.org> wrote: > > > Another reason to prefer it: stand-alone bzr binaries are available and > > work *now* in Windows. > > That's also true of mercurial, monotone, darcs and git, depending of > how you do define "work now". > > Juanma > > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-devel > -- Sent from Gmail for mobile | mobile.google.com Contents reflect my personal views only! ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-24 15:34 ` dhruva @ 2008-01-24 19:52 ` Stephen J. Turnbull 2008-01-25 0:43 ` Juanma Barranquero 2008-01-25 22:47 ` Richard Stallman 0 siblings, 2 replies; 258+ messages in thread From: Stephen J. Turnbull @ 2008-01-24 19:52 UTC (permalink / raw) To: dhruva; +Cc: Juanma Barranquero, emacs-devel dhruva writes: > feature I consider very good. Ability to run a git server for existing > cvs clients. Though this might be contradictory to dVCS concepts (not > too sure though) CVS would be a reasonably useful alternative protocol for update-only workspaces except for the fact that many firewalls block port 2401. > On 1/24/08, Juanma Barranquero <lekktu@gmail.com> wrote: > > That's also true of mercurial, monotone, darcs and git, depending of > > how you do define "work now". Darcs does not "work now" any platform if in "work" you include "cheap branches". Darcs does not "work now" on any platform, if in "work" you include "reliably delivers pushes and pulls in time similar to CVS." Posts by Darcs users (some of them long-timers) that they feel forced to abandon Darcs or to move mission-critical repos to a different VCS are a common occurrance. Darcs 2, now in very early beta, addresses the first concern very well according to benchmarks published on the developers list. Similarly, it partially addresses the second concern based on those benchmarks. However, it is not clear that the "exponential-time merge" problem is being addressed, and there is no real-world experience with Darcs 2 yet (it's not even self-hosting). I would guess that in the time frame that Emacs is making the choice, we'll see both Darcs 2 and GHC (the Glasgow Haskell Compiler used to build Darcs) move their repos to Darcs 2. So don't rule Darcs out. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-24 19:52 ` Stephen J. Turnbull @ 2008-01-25 0:43 ` Juanma Barranquero 2008-01-25 22:47 ` Richard Stallman 1 sibling, 0 replies; 258+ messages in thread From: Juanma Barranquero @ 2008-01-25 0:43 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel On Jan 24, 2008 8:52 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote: > I would guess that in the time frame that Emacs is making the choice, > we'll see both Darcs 2 and GHC (the Glasgow Haskell Compiler used to > build Darcs) move their repos to Darcs 2. So don't rule Darcs out. I know this, I follow several Haskell lists, glasgow-haskell-users among them. My point wasn't about darcs shortcomings, but to stress than having "stand-alone binaries available and working *now* in Windows" will hardly be a deciding factor; not because I don't think it is important (I do), but because any reasonable candidate dVCS already works on Windows, to a lesser or greater extent. Juanma ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-24 19:52 ` Stephen J. Turnbull 2008-01-25 0:43 ` Juanma Barranquero @ 2008-01-25 22:47 ` Richard Stallman 2008-01-25 23:13 ` Alfred M. Szmidt 1 sibling, 1 reply; 258+ messages in thread From: Richard Stallman @ 2008-01-25 22:47 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel, lekktu GNU projects should use and thus support other GNU projects, as a matter of loyalty. So if bzr becomes a GNU package, we should use bzr. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-25 22:47 ` Richard Stallman @ 2008-01-25 23:13 ` Alfred M. Szmidt 2008-01-25 23:36 ` Miles Bader 2008-01-26 1:23 ` Thomas Lord 0 siblings, 2 replies; 258+ messages in thread From: Alfred M. Szmidt @ 2008-01-25 23:13 UTC (permalink / raw) To: rms; +Cc: lekktu, stephen, emacs-devel GNU projects should use and thus support other GNU projects, as a matter of loyalty. So if bzr becomes a GNU package, we should use bzr. For the record, we have tla which does what bzr does. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-25 23:13 ` Alfred M. Szmidt @ 2008-01-25 23:36 ` Miles Bader 2008-01-27 0:45 ` Richard Stallman 2008-01-26 1:23 ` Thomas Lord 1 sibling, 1 reply; 258+ messages in thread From: Miles Bader @ 2008-01-25 23:36 UTC (permalink / raw) To: ams; +Cc: lekktu, stephen, rms, emacs-devel "Alfred M. Szmidt" <ams@gnu.org> writes: > GNU projects should use and thus support other GNU projects, as a > matter of loyalty. So if bzr becomes a GNU package, we should use > bzr. > > For the record, we have tla which does what bzr does. I'd hope bzr would be at least a _bit_ better, given that it's explicitly an attempt to rewrite tla from scratch and fix its problems (or at least problems as canonical perceived them). I don't know that I like the idea of an inferior system being promoted simply because it has an arbitrary label attached though... -Miles -- 97% of everything is grunge ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-25 23:36 ` Miles Bader @ 2008-01-27 0:45 ` Richard Stallman 2008-01-27 17:39 ` David Kastrup 0 siblings, 1 reply; 258+ messages in thread From: Richard Stallman @ 2008-01-27 0:45 UTC (permalink / raw) To: Miles Bader; +Cc: lekktu, ams, stephen, emacs-devel I don't know that I like the idea of an inferior system being promoted simply because it has an arbitrary label attached though... Being part of the GNU Project is not an arbitrary label. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-27 0:45 ` Richard Stallman @ 2008-01-27 17:39 ` David Kastrup 2008-01-27 20:06 ` Nick Roberts 2008-01-28 7:18 ` What a modern collaboration toolkit looks like Richard Stallman 0 siblings, 2 replies; 258+ messages in thread From: David Kastrup @ 2008-01-27 17:39 UTC (permalink / raw) To: rms; +Cc: lekktu, ams, emacs-devel, stephen, Miles Bader Richard Stallman <rms@gnu.org> writes: > I don't know that I like the idea of an inferior system being > promoted simply because it has an arbitrary label attached > though... > > Being part of the GNU Project is not an arbitrary label. It is not a label given for technical excellence. And as far as I am able to see, the promotion to "GNU software" is not the result of a competition for that title, but is granted when certain criteria are met and an application is made. The FSF as the authority granting the label of "GNU" does not at the same time have developer resources it can devote or reroute to GNU software. There are quite a few GNU software projects that are stagnating because of a lack of developers. It would not magically create new contributors when something important like Emacs development is hobbled by being tied into a project that does not, while deserving the name GNOME, have the impetus and capability to keep Emacs running. A development infrastructure depending on non-free software is unfortunate, one depending on free non-GNU software is not, as far as I can see, problematic over one depending on a resource-starved GNU project: one could always fork the free non-GNU software and would start with the same manpower (namely none) than one has for a stalling GNU project. So I don't think we should let ourselves be guided too much by the non-GNU/GNU distinction for development infrastructure when the GNU software does not fit the bill and we have no way making it do so. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-27 17:39 ` David Kastrup @ 2008-01-27 20:06 ` Nick Roberts 2008-01-27 22:21 ` David Kastrup ` (3 more replies) 2008-01-28 7:18 ` What a modern collaboration toolkit looks like Richard Stallman 1 sibling, 4 replies; 258+ messages in thread From: Nick Roberts @ 2008-01-27 20:06 UTC (permalink / raw) To: David Kastrup; +Cc: rms, lekktu, emacs-devel, ams, stephen, Miles Bader > > Being part of the GNU Project is not an arbitrary label. > > It is not a label given for technical excellence. And as far as I am > able to see, the promotion to "GNU software" is not the result of a > competition for that title, but is granted when certain criteria are met > and an application is made. I have presumed that it requires assigning all copyright to the FSF which means that projects which have no record of authorship cannot become GNU projects. I'm interested to know what it means to be part of the GNU Project because I work on both Emacs and GDB but, in practice, I can see no formal synergy between the two, or preference towards each other. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-27 20:06 ` Nick Roberts @ 2008-01-27 22:21 ` David Kastrup 2008-01-27 23:58 ` Johan Bockgård ` (2 subsequent siblings) 3 siblings, 0 replies; 258+ messages in thread From: David Kastrup @ 2008-01-27 22:21 UTC (permalink / raw) To: Nick Roberts; +Cc: rms, lekktu, emacs-devel, ams, stephen, Miles Bader Nick Roberts <nickrob@snap.net.nz> writes: > > > Being part of the GNU Project is not an arbitrary label. > > > > It is not a label given for technical excellence. And as far as I am > > able to see, the promotion to "GNU software" is not the result of a > > competition for that title, but is granted when certain criteria are met > > and an application is made. > > I have presumed that it requires assigning all copyright to the FSF > which means that projects which have no record of authorship cannot > become GNU projects. Emacs does not have all copyright assigned to the FSF (for example, the MULE subsystem is copyrighted by the Japanese Government or something like that). So the assignment in toto is not an absolutely rigid and exceptionless rule. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-27 20:06 ` Nick Roberts 2008-01-27 22:21 ` David Kastrup @ 2008-01-27 23:58 ` Johan Bockgård 2008-01-28 7:17 ` Richard Stallman 2008-01-28 7:17 ` Richard Stallman 3 siblings, 0 replies; 258+ messages in thread From: Johan Bockgård @ 2008-01-27 23:58 UTC (permalink / raw) To: emacs-devel Nick Roberts <nickrob@snap.net.nz> writes: > I have presumed that it requires assigning all copyright to the FSF > which means that projects which have no record of authorship cannot > become GNU projects. "For a program to be GNU software does not require transferring copyright to the FSF; that is a separate question. If you transfer the copyright to the FSF, the FSF will enforce the GPL for the program if someone violates it; if you keep the copyright, enforcement will be up to you." http://www.gnu.org/help/evaluation.html -- Johan Bockgård ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-27 20:06 ` Nick Roberts 2008-01-27 22:21 ` David Kastrup 2008-01-27 23:58 ` Johan Bockgård @ 2008-01-28 7:17 ` Richard Stallman 2008-01-28 7:17 ` Richard Stallman 3 siblings, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-28 7:17 UTC (permalink / raw) To: Nick Roberts; +Cc: lekktu, emacs-devel, ams, stephen, miles Some GNU packages are copyright FSF, some are not. The developers of a package decide to transfer the copyright or not. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-27 20:06 ` Nick Roberts ` (2 preceding siblings ...) 2008-01-28 7:17 ` Richard Stallman @ 2008-01-28 7:17 ` Richard Stallman 2008-01-28 7:57 ` GNU Project [was: Re: What a modern collaboration toolkit looks like] Nick Roberts 3 siblings, 1 reply; 258+ messages in thread From: Richard Stallman @ 2008-01-28 7:17 UTC (permalink / raw) To: Nick Roberts; +Cc: lekktu, emacs-devel, ams, stephen, miles I'm interested to know what it means to be part of the GNU Project because I work on both Emacs and GDB but, in practice, I can see no formal synergy between the two, or preference towards each other. We should be designing them both to work well together. For instance, the GDB developers should pay attention to what your Emacs work needs. (I'm not sure whether the terms "formal synergy" or "preference towards" fit this.) ^ permalink raw reply [flat|nested] 258+ messages in thread
* GNU Project [was: Re: What a modern collaboration toolkit looks like] 2008-01-28 7:17 ` Richard Stallman @ 2008-01-28 7:57 ` Nick Roberts 2008-01-28 21:32 ` Richard Stallman 0 siblings, 1 reply; 258+ messages in thread From: Nick Roberts @ 2008-01-28 7:57 UTC (permalink / raw) To: rms; +Cc: emacs-devel > I'm interested to know what it means to be part of the GNU Project > because I work on both Emacs and GDB but, in practice, I can see no > formal synergy between the two, or preference towards each other. > > We should be designing them both to work well together. For instance, > the GDB developers should pay attention to what your Emacs work needs. Yes, but that much would be true for any other free software project like kdevelop or cgdb. From reading http://www.gnu.org/help/evaluation.html it seems to basically imply availability ftp.gnu.org on and consistency in coding, documentation and licencing. With regard to the latter, it sounds a bit like a certification. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: GNU Project [was: Re: What a modern collaboration toolkit looks like] 2008-01-28 7:57 ` GNU Project [was: Re: What a modern collaboration toolkit looks like] Nick Roberts @ 2008-01-28 21:32 ` Richard Stallman 0 siblings, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-28 21:32 UTC (permalink / raw) To: Nick Roberts; +Cc: emacs-devel > We should be designing them both to work well together. For instance, > the GDB developers should pay attention to what your Emacs work needs. Yes, but that much would be true for any other free software project like kdevelop or cgdb. Those programs are other projects, not part of our project. It is good to help them when possible, but GNU packages get special priority. From reading http://www.gnu.org/help/evaluation.html it seems to basically imply availability ftp.gnu.org on and consistency in coding, documentation and licencing. Those are some of the specific practical conditions and requirements, but don't neglect the forest for the trees. Those specific practical points are aspects of being part of one larger project. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-27 17:39 ` David Kastrup 2008-01-27 20:06 ` Nick Roberts @ 2008-01-28 7:18 ` Richard Stallman 2008-01-28 7:30 ` David Kastrup 1 sibling, 1 reply; 258+ messages in thread From: Richard Stallman @ 2008-01-28 7:18 UTC (permalink / raw) To: David Kastrup; +Cc: lekktu, ams, emacs-devel, stephen, miles I think you have the wrong picture of the issue. All the GNU packages are part of one joint project to develop an operating system. To achieve this we must support each other. To keep ourselves honest, we must use other GNU packages whenever they are fit for use. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-28 7:18 ` What a modern collaboration toolkit looks like Richard Stallman @ 2008-01-28 7:30 ` David Kastrup 2008-01-28 9:18 ` Stephen J. Turnbull 2008-01-28 21:32 ` Richard Stallman 0 siblings, 2 replies; 258+ messages in thread From: David Kastrup @ 2008-01-28 7:30 UTC (permalink / raw) To: rms; +Cc: lekktu, ams, emacs-devel, stephen, miles Richard Stallman <rms@gnu.org> writes: > I think you have the wrong picture of the issue. That implies that there is only one right picture. > All the GNU packages are part of one joint project to develop an > operating system. To achieve this we must support each other. To > keep ourselves honest, we must use other GNU packages whenever they > are fit for use. Using a package is not the same as supporting it: it actually places additional burdens on its developers. When there are no additional resources moved to them as well, their package has no tangible advantage from this sort of "support". And when this makes the sitation worse at the "supporting" package, the total situation is a loss for GNU. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-28 7:30 ` David Kastrup @ 2008-01-28 9:18 ` Stephen J. Turnbull 2008-01-28 21:32 ` Richard Stallman 1 sibling, 0 replies; 258+ messages in thread From: Stephen J. Turnbull @ 2008-01-28 9:18 UTC (permalink / raw) To: David Kastrup; +Cc: lekktu, ams, miles, rms, emacs-devel David Kastrup writes: > Using a package is not the same as supporting it: it actually places > additional burdens on its developers. When there are no additional > resources moved to them as well, their package has no tangible advantage > from this sort of "support". And when this makes the sitation worse at > the "supporting" package, the total situation is a loss for GNU. But this has become an abstract policy discussion, because I don't think either is true in the case in point. bzr is well-endowed with development resources, as it is a mission- critical part of its maintainer's[1] infrastructure, but small in comparison to the organization as a whole. They are not going to notice additional burden from Emacs's use. Nor is it going to make the Emacs development environment worse than continued dependence on CVS does. I don't know of any projects that switched from CVS or Subversion to bzr that ever looked back. Footnotes: [1] Well, of course the GNU maintainer (is there one/more yet? couldn't find one) will not be a corporation, but for these purposes bzr is maintained by Canonical, not by any one person. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-28 7:30 ` David Kastrup 2008-01-28 9:18 ` Stephen J. Turnbull @ 2008-01-28 21:32 ` Richard Stallman 1 sibling, 0 replies; 258+ messages in thread From: Richard Stallman @ 2008-01-28 21:32 UTC (permalink / raw) To: David Kastrup; +Cc: lekktu, ams, emacs-devel, stephen, miles > I think you have the wrong picture of the issue. That implies that there is only one right picture. I don't know whether there is more than one right picture, but you're using the wrong one. To approach things that way would be contrary to the responsibilities of a GNU package maintainer. It is out of the question. To argue for that just shows you don't understand. Using a package is not the same as supporting it: it actually places additional burdens on its developers. That is too narrow a picture of "support". Using a package is a vital form of support. ^ permalink raw reply [flat|nested] 258+ messages in thread
* Re: What a modern collaboration toolkit looks like 2008-01-25 23:13 ` Alfred M. Szmidt 2008-01-25 23:36 ` Miles Bader @ 2008-01-26 1:23 ` Thomas Lord 1 sibling, 0 replies; 258+ messages in thread From: Thomas Lord @ 2008-01-26 1:23 UTC (permalink / raw) To: ams; +Cc: lekktu, stephen, rms, emacs-devel Alfred M. Szmidt wrote: > GNU projects should use and thus support other GNU projects, as a > matter of loyalty. So if bzr becomes a GNU package, we should use > bzr. > > For the record, we have tla which does what bzr does. > > Oops. Though I had resolved to say next to nothing on this list I must poke in here. Tla helped give birth to bzr. Bzr is completely rewritten, as far as I know. Bzr is defined by large amounts of creative contribution that have nothing to do with me. But: tla really helped lead to bzr, fairly directly. The point is, that it does not disrespect the GNU Arch project to consider GNU-izing and organizing around bzr. That is a technical question and it is a legal, economic and ethical question about how the project will be run in the future -- but, if I have any authority on the matter, adopting bzr is not per se any kind of disloyalty to tla. tla, -t ^ permalink raw reply [flat|nested] 258+ messages in thread
end of thread, other threads:[~2008-01-28 21:32 UTC | newest] Thread overview: 258+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-12-30 12:22 What a modern collaboration toolkit looks like Eric S. Raymond 2007-12-30 15:32 ` Thien-Thi Nguyen 2007-12-30 15:42 ` Richard Stallman 2007-12-30 17:22 ` Eric S. Raymond 2007-12-30 20:25 ` Robert J. Chassell 2007-12-30 21:55 ` Nick Roberts 2007-12-30 22:25 ` Lennart Borgman (gmail) 2007-12-30 22:58 ` Richard Stallman 2007-12-30 22:58 ` Richard Stallman 2007-12-31 2:58 ` Eric S. Raymond 2007-12-31 12:14 ` Thien-Thi Nguyen 2008-01-01 23:57 ` John S. Yates, Jr. 2008-01-02 1:46 ` Thien-Thi Nguyen 2007-12-31 22:29 ` Richard Stallman 2008-01-01 0:19 ` Leo 2007-12-31 4:31 ` Eli Zaretskii 2007-12-31 13:07 ` Eric S. Raymond 2007-12-31 20:57 ` Eli Zaretskii 2007-12-31 21:41 ` Eric S. Raymond 2007-12-31 23:00 ` Nick Roberts 2008-01-01 0:50 ` Eric S. Raymond 2008-01-01 4:22 ` Eli Zaretskii 2008-01-01 6:20 ` Eric S. Raymond 2007-12-31 23:12 ` Eli Zaretskii 2008-01-01 0:27 ` Dan Nicolaescu 2008-01-01 3:00 ` Mike Mattie 2008-01-01 7:57 ` Drew Adams 2008-01-02 19:28 ` Agustin Martin 2008-01-03 9:50 ` Richard Stallman 2008-01-05 3:34 ` Mike Mattie 2008-01-06 8:09 ` Richard Stallman 2008-01-03 9:50 ` Richard Stallman 2008-01-01 20:44 ` Eli Zaretskii 2008-01-02 4:17 ` Dan Nicolaescu 2008-01-05 10:48 ` Eli Zaretskii 2008-01-01 0:57 ` Eric S. Raymond 2008-01-01 4:21 ` Eli Zaretskii 2008-01-01 0:10 ` Miles Bader 2008-01-01 1:06 ` Eric S. Raymond 2008-01-01 1:41 ` Miles Bader 2008-01-01 2:16 ` Eric S. Raymond 2008-01-01 19:43 ` Tom Tromey 2008-01-01 21:11 ` Nick Roberts 2008-01-02 0:25 ` Miles Bader 2008-01-02 1:12 ` Tom Tromey 2008-01-02 17:19 ` On-the-fly compiling (was Re: What a modern collaboration toolkit looks like) Mark A. Hershberger 2008-01-02 20:57 ` On-the-fly compiling Stefan Monnier 2008-01-02 22:33 ` Lennart Borgman (gmail) 2008-01-02 23:09 ` Tom Tromey 2008-01-02 9:53 ` What a modern collaboration toolkit looks like Richard Stallman 2008-01-01 11:28 ` Tassilo Horn 2008-01-01 20:36 ` Eli Zaretskii 2008-01-02 0:29 ` Miles Bader 2008-01-02 4:14 ` Eli Zaretskii 2008-01-02 4:33 ` Miles Bader 2008-01-02 8:24 ` Werner LEMBERG 2008-01-02 8:20 ` Tassilo Horn 2008-01-03 9:50 ` Richard Stallman 2008-01-03 13:15 ` Ævar Arnfjörð Bjarmason 2008-01-04 13:56 ` Stefan Monnier 2008-01-02 8:41 ` tomas 2008-01-03 9:50 ` Richard Stallman 2008-01-03 10:16 ` Miles Bader 2008-01-05 5:55 ` Richard Stallman 2008-01-05 6:59 ` Óscar Fuentes 2008-01-05 15:29 ` Eli Zaretskii 2008-01-05 19:53 ` Óscar Fuentes 2008-01-06 8:09 ` Richard Stallman 2008-01-05 8:55 ` David Kastrup 2008-01-05 9:55 ` Werner LEMBERG 2008-01-05 15:23 ` Eli Zaretskii 2008-01-05 15:31 ` Lars Magne Ingebrigtsen 2008-01-05 15:39 ` David Kastrup 2008-01-06 8:09 ` Richard Stallman 2008-01-06 9:51 ` tomas 2008-01-06 11:02 ` David Kastrup 2008-01-06 12:05 ` Robert J. Chassell 2008-01-06 12:40 ` David Kastrup 2008-01-06 16:51 ` Robert J. Chassell 2008-01-06 17:03 ` David Kastrup 2008-01-07 4:18 ` Richard Stallman 2008-01-05 22:46 ` Stefan Monnier 2008-01-06 18:09 ` Richard Stallman 2008-01-07 17:17 ` Gregory Collins 2008-01-07 23:21 ` Stephen J. Turnbull 2008-01-08 0:25 ` Gregory Collins 2008-01-08 0:51 ` David Kastrup 2008-01-08 2:43 ` Mike Mattie 2008-01-08 3:03 ` YAMAMOTO Mitsuharu 2008-01-08 4:25 ` Mike Mattie 2008-01-08 19:07 ` Richard Stallman 2008-01-03 10:32 ` David Kastrup 2008-01-01 17:11 ` Alan Mackenzie 2008-01-01 18:05 ` Werner LEMBERG 2008-01-01 18:27 ` Alan Mackenzie 2008-01-01 18:28 ` Werner LEMBERG 2008-01-02 9:53 ` Richard Stallman 2008-01-02 10:36 ` Werner LEMBERG 2008-01-02 12:23 ` Eric S. Raymond 2008-01-04 5:27 ` Richard Stallman 2008-01-02 11:27 ` Thien-Thi Nguyen 2008-01-02 12:17 ` Eric S. Raymond 2008-01-03 1:26 ` Stephen J. Turnbull 2008-01-03 2:49 ` Eric S. Raymond 2008-01-04 5:27 ` Richard Stallman 2008-01-04 5:35 ` Miles Bader 2008-01-04 12:47 ` Eric S. Raymond 2008-01-05 14:30 ` Richard Stallman 2008-01-06 1:10 ` Miles Bader 2008-01-04 12:45 ` Eric S. Raymond 2008-01-05 14:30 ` Richard Stallman 2008-01-05 15:29 ` Eric S. Raymond 2008-01-05 15:59 ` Andreas Schwab 2008-01-06 2:14 ` Mike Mattie 2008-01-03 1:08 ` Giorgos Keramidas 2008-01-03 2:56 ` Eric S. Raymond 2008-01-03 3:18 ` Giorgos Keramidas 2008-01-04 5:27 ` Richard Stallman 2008-01-04 8:51 ` David Kastrup 2008-01-05 14:30 ` Richard Stallman 2008-01-05 15:28 ` David Kastrup 2008-01-06 10:46 ` Richard Stallman 2008-01-06 11:10 ` David Kastrup 2008-01-07 4:18 ` Richard Stallman 2008-01-07 4:36 ` dhruva 2008-01-07 4:52 ` Sam Steingold 2008-01-07 5:09 ` dhruva 2008-01-07 8:17 ` David Kastrup 2008-01-07 15:37 ` Stefan Monnier 2008-01-07 15:47 ` David Kastrup 2008-01-07 16:22 ` Stefan Monnier 2008-01-07 17:09 ` David Kastrup 2008-01-07 15:40 ` CHENG Gao 2008-01-07 23:36 ` Stephen J. Turnbull 2008-01-08 4:31 ` CHENG Gao 2008-01-08 5:07 ` Mike Mattie 2008-01-08 2:56 ` Mike Mattie 2008-01-08 9:37 ` Andreas Schwab 2008-01-07 5:16 ` Jason Earl 2008-01-07 17:16 ` Richard Stallman 2008-01-07 17:45 ` Gregory Collins 2008-01-08 19:07 ` Richard Stallman 2008-01-08 19:50 ` Miles Bader 2008-01-13 20:06 ` Giorgos Keramidas 2008-01-14 11:28 ` Richard Stallman 2008-01-07 21:28 ` Jason Earl 2008-01-07 8:15 ` David Kastrup 2008-01-07 8:33 ` Giorgos Keramidas 2008-01-07 23:50 ` Stephen J. Turnbull 2008-01-05 21:11 ` Stephen J. Turnbull 2008-01-06 18:08 ` Richard Stallman 2008-01-07 9:35 ` Piet van Oostrum 2008-01-01 20:53 ` Nick Roberts 2008-01-02 9:53 ` Richard Stallman 2008-01-02 12:24 ` Eric S. Raymond 2008-01-02 15:19 ` David Kastrup 2008-01-02 20:35 ` Karl Fogel 2008-01-02 19:19 ` Andreas Schwab 2008-01-02 19:23 ` Romain Francoise 2008-01-03 1:18 ` Giorgos Keramidas 2008-01-03 7:55 ` David Kastrup 2008-01-02 9:53 ` Richard Stallman 2008-01-02 10:03 ` David Kastrup 2008-01-02 10:05 ` Tassilo Horn 2008-01-02 11:31 ` Alan Mackenzie 2008-01-02 11:28 ` Tassilo Horn 2008-01-02 14:26 ` Óscar Fuentes 2008-01-02 19:48 ` Karl Fogel 2008-01-02 18:43 ` Andreas Schwab 2008-01-02 22:10 ` Alfred M. Szmidt 2008-01-03 2:58 ` Karl Fogel 2008-01-03 1:21 ` Giorgos Keramidas 2008-01-03 9:14 ` Andreas Schwab 2008-01-03 10:57 ` Giorgos Keramidas 2008-01-01 19:37 ` Eric S. Raymond 2008-01-01 21:46 ` Alan Mackenzie 2008-01-01 22:49 ` Eric S. Raymond 2008-01-02 17:05 ` Mark A. Hershberger 2008-01-03 9:49 ` Richard Stallman 2008-01-02 8:35 ` Tassilo Horn 2008-01-02 5:54 ` John S. Yates, Jr. 2008-01-02 11:52 ` Eric S. Raymond 2008-01-03 9:50 ` Richard Stallman 2008-01-02 8:51 ` tomas 2008-01-02 9:53 ` Richard Stallman 2008-01-01 22:01 ` Romain Francoise 2007-12-31 13:11 ` Alan Mackenzie 2007-12-31 13:24 ` Miles Bader 2007-12-31 13:44 ` Alan Mackenzie 2007-12-31 15:45 ` Eric S. Raymond 2007-12-31 15:14 ` Juanma Barranquero 2007-12-31 15:31 ` Eric S. Raymond 2007-12-31 15:25 ` Eric S. Raymond 2008-01-01 20:34 ` Alan Mackenzie 2008-01-01 20:57 ` Eric S. Raymond 2008-01-02 9:53 ` Richard Stallman 2008-01-02 12:29 ` Eric S. Raymond 2008-01-02 12:59 ` dhruva 2008-01-02 13:11 ` Miles Bader 2008-01-02 13:17 ` Tassilo Horn 2008-01-02 13:49 ` David Kastrup 2008-01-04 5:28 ` Richard Stallman 2008-01-04 7:03 ` John S. Yates, Jr. 2008-01-05 14:29 ` Richard Stallman 2008-01-02 13:48 ` Werner LEMBERG 2008-01-02 13:56 ` dhruva 2008-01-02 14:55 ` Eric S. Raymond 2008-01-03 1:13 ` Giorgos Keramidas 2008-01-02 14:50 ` Eric S. Raymond 2008-01-19 17:45 ` Jari Aalto 2008-01-20 2:59 ` dhruva 2008-01-20 5:10 ` Miles Bader 2008-01-20 5:36 ` Juanma Barranquero 2008-01-20 6:03 ` Miles Bader 2008-01-20 19:28 ` Eli Zaretskii 2008-01-20 20:42 ` Juanma Barranquero 2008-01-20 20:17 ` Juanma Barranquero 2008-01-20 20:28 ` Juanma Barranquero 2008-01-21 2:11 ` Miles Bader 2008-01-21 2:38 ` Karl Fogel 2008-01-21 2:49 ` Miles Bader 2008-01-21 3:06 ` Nick Roberts 2008-01-21 3:17 ` Miles Bader 2008-01-21 3:26 ` Stephen J. Turnbull 2008-01-21 3:16 ` Glenn Morris 2008-01-21 4:11 ` Nick Roberts 2008-01-21 10:00 ` Thien-Thi Nguyen 2008-01-21 2:41 ` Juanma Barranquero 2008-01-21 3:01 ` Nick Roberts 2008-01-21 9:07 ` Richard Stallman 2008-01-21 15:51 ` Dan Nicolaescu 2008-01-21 17:37 ` Miles Bader 2008-01-21 17:53 ` Tom Tromey 2008-01-21 20:06 ` Stefan Monnier 2008-01-21 19:50 ` Tom Tromey 2008-01-22 0:33 ` Dan Nicolaescu 2008-01-24 14:43 ` Mark A. Hershberger 2008-01-24 15:00 ` Juanma Barranquero 2008-01-24 15:34 ` dhruva 2008-01-24 19:52 ` Stephen J. Turnbull 2008-01-25 0:43 ` Juanma Barranquero 2008-01-25 22:47 ` Richard Stallman 2008-01-25 23:13 ` Alfred M. Szmidt 2008-01-25 23:36 ` Miles Bader 2008-01-27 0:45 ` Richard Stallman 2008-01-27 17:39 ` David Kastrup 2008-01-27 20:06 ` Nick Roberts 2008-01-27 22:21 ` David Kastrup 2008-01-27 23:58 ` Johan Bockgård 2008-01-28 7:17 ` Richard Stallman 2008-01-28 7:17 ` Richard Stallman 2008-01-28 7:57 ` GNU Project [was: Re: What a modern collaboration toolkit looks like] Nick Roberts 2008-01-28 21:32 ` Richard Stallman 2008-01-28 7:18 ` What a modern collaboration toolkit looks like Richard Stallman 2008-01-28 7:30 ` David Kastrup 2008-01-28 9:18 ` Stephen J. Turnbull 2008-01-28 21:32 ` Richard Stallman 2008-01-26 1:23 ` Thomas Lord
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).