From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Re: Org-mode development Date: Sat, 29 Dec 2007 13:11:22 +0100 Message-ID: <877iixu2dx.fsf@bzg.ath.cx> References: <200712270951.52114.david.daniel.smith@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J8aXJ-0002lz-3v for emacs-orgmode@gnu.org; Sat, 29 Dec 2007 07:11:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J8aXI-0002kc-C6 for emacs-orgmode@gnu.org; Sat, 29 Dec 2007 07:11:28 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8aXI-0002kP-6s for emacs-orgmode@gnu.org; Sat, 29 Dec 2007 07:11:28 -0500 Received: from fg-out-1718.google.com ([72.14.220.156]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J8aXH-0006S1-V4 for emacs-orgmode@gnu.org; Sat, 29 Dec 2007 07:11:28 -0500 Received: by fg-out-1718.google.com with SMTP id d23so2429388fga.30 for ; Sat, 29 Dec 2007 04:11:27 -0800 (PST) In-Reply-To: <200712270951.52114.david.daniel.smith@gmail.com> (David Smith's message of "Thu, 27 Dec 2007 09:51:39 +0900") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: David Smith Cc: emacs-orgmode@gnu.org Hi David, David Smith writes: > I couldn't wait any longer so I went ahead and set up a mercurial repository > starting with the current 5.17a. I would have liked to have imported older > history but it was a lot of work so hopefully Carsten can just send them to > me and put them in later. > > The repository is available at http://hg.bosabosa.org/orgmode/ Thanks for setting this up. I think this is a good idea, but my idea of why this is a good idea might slightly differ from yours. This is a good idea insofar that it provides a place where people can experiment with Org code freely. But I'm a bit skeptical over whether this will really fit Org's development constraints -- of course, only Carsten can decide on this. The Linus/Carsten parallel is limited. The Linux kernel is really self-contained, while Org is part of Emacs. This makes a difference. Letting code sneaking in Org is not only a matter of having FSF papers signed, but also of making sure that the code fits with general Emacs conventions. This require special attention, and such attention might be easier to provide in a somewhat centralized development framework. > Carsten brought up the very good issue that any patches that get into > the official branch need to have copyright assigned to the FSF. > > This is easy to handle: there will be a separate repository managed by > either Carsten or, if he doesn't want to, by me for merging patches > once they have FSF copyright assignment. This is a trade-off. With a repository you need to spend time checking about legal issues and - as I pointed out above - about "Emacs-ability" of the patches. My feeling is that there will be too much energy spent on coordination here -- and I guess Carsten prefers coding. Note: Linus said that git spares you the cost of coordination, but he's really speaking about something very specific: coordinating people thru git vs. coordinating them thru cvs (i.e. handling branches with git vs. handling branches with cvs.) Again: having an external repo is a great way to experiment with code. And no matter whether Org is developed thru it or not, you can always manage the repo and submit interesting patches to the mailing list. > Carsten's role of shaping and filtering features sounds exactly like > Linus's role in Linux and so this development model should work well > and scale better then what we've done in the past. I think the current development model works okay -- until Carsten feels to much pressure and doesn't want to cope with it anymore :) The area where we need to "scale better" is that of providing tutorials, screencasts, FAQs, etc. That fact that Org attracts lots of agile geeks shouldn't let us forget about this aspect... and I believe this is where a decentralized development model would *really* help. > Hopefully, ease-of-use won't be a problem with mercurial. (I've never worked with mercurial yet, but I know git a bit and I think the switch is not a sweat.) > I'll be putting my personal patches there for things like trac bugs > integration, ical import, taskjuggler export, html export > improvements, and css and javascript for the exported html pages. Great! I'll be checking your repo and see whether I can contribute. But the example you give confirms that the repo is more a place where to put Org-related code rather than a place where to develop Org itself. For example, I guess add-ons about javascript for the exported HTML pages can't live in Emacs... but will be helpful for some people. > Hopefully others will fork mercurial repos as well, and send patches > around. Thanks for bringing this up again! Hopefully my points are not too dim :) -- Bastien