From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: What a modern collaboration toolkit looks like Date: Wed, 02 Jan 2008 09:20:01 +0100 Message-ID: <87wsqsvdu6.fsf@member.fsf.org> References: <20071230122217.3CA84830B9A@snark.thyrsus.com> <20071231130712.GB8641@thyrsus.com> <87y7b96az8.fsf@member.fsf.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199262017 23366 80.91.229.12 (2 Jan 2008 08:20:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Jan 2008 08:20:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 02 09:20:36 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J9yq4-0004J9-GG for ged-emacs-devel@m.gmane.org; Wed, 02 Jan 2008 09:20:36 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J9ypi-00031l-Dk for ged-emacs-devel@m.gmane.org; Wed, 02 Jan 2008 03:20:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J9ypd-0002yC-Gm for emacs-devel@gnu.org; Wed, 02 Jan 2008 03:20:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J9ypY-0002lt-Gm for emacs-devel@gnu.org; Wed, 02 Jan 2008 03:20:08 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J9ypY-0002lc-Cf for emacs-devel@gnu.org; Wed, 02 Jan 2008 03:20:04 -0500 Original-Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J9ypY-0003F6-2y for emacs-devel@gnu.org; Wed, 02 Jan 2008 03:20:04 -0500 Original-Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id D278482C34 for ; Wed, 2 Jan 2008 03:20:03 -0500 (EST) Original-Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 02 Jan 2008 03:20:03 -0500 X-Sasl-enc: 5DqR1RwfpEvARjKbfjy4e2axeTsrMEB5HFRyLE9XnYje 1199262003 Original-Received: from baldur (dslb-084-063-049-086.pools.arcor-ip.net [84.63.49.86]) by mail.messagingengine.com (Postfix) with ESMTP id C7332592C for ; Wed, 2 Jan 2008 03:20:02 -0500 (EST) Mail-Followup-To: emacs-devel@gnu.org In-Reply-To: (Eli Zaretskii's message of "Tue, 01 Jan 2008 22:36:30 +0200") User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.50 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:85863 Archived-At: Eli Zaretskii 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