From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suvayu Ali Subject: Re: Thanks for Lilypond export (and minor comments) Date: Sun, 10 Jul 2011 18:50:58 +0200 Message-ID: <20110710185058.2e29b13d@kuru.homelinux.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([140.186.70.92]:47238) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfxDm-0004qq-Lx for emacs-orgmode@gnu.org; Sun, 10 Jul 2011 12:51:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QfxDk-0005rd-NS for emacs-orgmode@gnu.org; Sun, 10 Jul 2011 12:51:06 -0400 Received: from mail-ew0-f41.google.com ([209.85.215.41]:34034) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfxDk-0005rO-CU for emacs-orgmode@gnu.org; Sun, 10 Jul 2011 12:51:04 -0400 Received: by ewy9 with SMTP id 9so1227489ewy.0 for ; Sun, 10 Jul 2011 09:51:02 -0700 (PDT) In-Reply-To: <87mxgnn8qq.fsf@gnu.org> 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: Bastien Cc: emacs-orgmode@gnu.org Hi Bastien, On Sat, 09 Jul 2011 10:44:45 +0200 Bastien wrote: > > http://www.kernel.org/pub/software/scm/git/docs/howto/maintain-git.txt > > Nice read, thanks. > > I guess the relevance of such a development model mainly depends on > how many developers are trying to collaborate, and at what pace. > > Let's see if a problem emerges from our current development model, and > how to fix it then. Of course. :) A model based on Junio's notes just came to my mind and I thought maybe I should share it just so that it stays in the archive for the future. So far I think we can break down the development of org into certain feature enhancements or new features and bug fixes. So maybe there could be topic branches based on master for the various features (lists, babel, latex export, odt export, any future attempt at code refactoring and so on) and a bugfix branch based on maint. Since usually a small set of devs work on each feature, it might be easier to collaborate and be more adventurous (since its not a change to master) during development. Also this would mean people interested in a specific feature could simply pull in the HEAD of these branches from time to time. And once the feature devs think the enhancements are relatively stable, you could pull it into master (a simple two way merge). Now since the bugfix branch is based on maint, it will be a lot easier to release critical fixes and could be merged into all branches (any topic branch or master). This will let you release point releases very easily (just fast-forward maint and tag). Master could host documentation or other non-critical bug fixes. For major releases you would need to do a few three-way merges (i.e. pulling several topic branches into master or pulling the bugfix branch into master) and finally make a commit changing the release tags and version strings and merge into maint and tag it as release_. Then the bugfix branch could be fast-forwarded to the new release and the process can start over again. To summarise, the above is solely based on merges and no need for tracking down individual commits (unless something goes wrong of course :-p). This makes full use of git's capability of three way merges and hopefully simplifies a lot of the maintainer tasks. :) PS: On the downside this does imply you would have to understand the various merge strategies git uses very well. :-p -- Suvayu Open source is the future. It sets us free.