Re: [O] Thanks for Lilypond export (and minor comments)

[Suvayu Ali]

Hi Bastien,

On Sat, 09 Jul 2011 10:44:45 +0200
Bastien <address@hidden> 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_<n+1>. 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.