From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Thanks for Lilypond export (and minor comments) Date: Mon, 11 Jul 2011 18:50:13 +0200 Message-ID: <87wrfosqwq.fsf@gnu.org> References: <9E8B5700-6008-4832-ACE1-BF471F129E0E@beds.ac.uk> <87sjqhdfn3.fsf@gnu.org> <874o2x1rfz.fsf@gmail.com> <87oc15nvv1.fsf@gnu.org> <17595.1310108424@alphaville.dokosmarshall.org> <87k4bt3zt4.fsf@gnu.org> <20110708180256.4d84bf95@kuru.homelinux.net> <87mxgnn8qq.fsf@gnu.org> <20110710185058.2e29b13d@kuru.homelinux.net> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:43319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgJmz-00072K-Fy for emacs-orgmode@gnu.org; Mon, 11 Jul 2011 12:56:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QgJmx-00029D-TZ for emacs-orgmode@gnu.org; Mon, 11 Jul 2011 12:56:57 -0400 Received: from mail-fx0-f52.google.com ([209.85.161.52]:46053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgJmw-00028v-Tt for emacs-orgmode@gnu.org; Mon, 11 Jul 2011 12:56:55 -0400 Received: by fxd18 with SMTP id 18so488342fxd.39 for ; Mon, 11 Jul 2011 09:56:53 -0700 (PDT) In-Reply-To: <20110710185058.2e29b13d@kuru.homelinux.net> (Suvayu Ali's message of "Sun, 10 Jul 2011 18:50:58 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Suvayu Ali Cc: emacs-orgmode@gnu.org Hi Suvayu, thanks for sharing this suggestion and to make it so clear. I understand the model you describe and I see why it's appropriate for projects like "git" -- as IIUC, your proposal is very close to the one described by git's maintainer. Let me summarize my ideas about how we should use git for Org. I have three principles. (1) git should reduce maintainer(s)'s work (2) git should let more developers submit patches (3) git should ease collaboration on fixes and new features I put them here in priority order. Yes, it means that I'm more interested in being lazy than in having more patches, and in having more patches than in easing collaboration between developers. I think it works so far for three reasons: - I'm not *that* lazy :) - The latest git HEAD is stable enough so that many people live on it, and can send feedback on patches. - Contributors rarely need to collaborate on fixes and features and when they do so, they collaborate by discussing on the mailing list. More branches (master, maint, feature-1,...) means more _incompressible_ work for the maintainers, even when they are ninjas of the git Three Way Merges. This additional work is only worth undertaking when people are *really* using the branches to collaborate -- which is quite unlikely to happen given the three reasons above, and also given the fact that the release pace of stable versions is quite fast. Last but not least, sticking to the current usage of git (i.e. commit into master as much as possible, commit only to maint for bugfixes that need to be released independantly) doesn't prevent using public branches from time to time -- we did it with Julien Danjou before. Hope it helps understanding my approach! It's all based on the idea "if it works, don't break it". But I'm open to any change if (and when) we need it. Best, -- Bastien