From: Suvayu Ali <fatkasuvayu+linux@gmail.com>
To: Bastien <bzg@altern.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: Thanks for Lilypond export (and minor comments)
Date: Sun, 10 Jul 2011 18:50:58 +0200 [thread overview]
Message-ID: <20110710185058.2e29b13d@kuru.homelinux.net> (raw)
In-Reply-To: <87mxgnn8qq.fsf@gnu.org>
Hi Bastien,
On Sat, 09 Jul 2011 10:44:45 +0200
Bastien <bzg@altern.org> 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.
next prev parent reply other threads:[~2011-07-10 16:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-07 16:38 Thanks for Lilypond export (and minor comments) Torsten Anders
2011-07-07 20:01 ` Bastien
2011-07-08 1:35 ` Eric Schulte
2011-07-08 6:13 ` Bastien
2011-07-08 7:00 ` Nick Dokos
2011-07-08 9:08 ` Bastien
2011-07-08 16:02 ` Suvayu Ali
2011-07-09 8:44 ` Bastien
2011-07-10 16:50 ` Suvayu Ali [this message]
2011-07-11 16:50 ` Bastien
2011-07-11 17:50 ` suvayu ali
2011-07-19 12:29 ` Bernt Hansen
2011-07-19 12:40 ` suvayu ali
2011-07-08 21:00 ` Achim Gratz
2011-07-09 8:46 ` Bastien
2011-07-08 7:56 ` Martyn Jago
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110710185058.2e29b13d@kuru.homelinux.net \
--to=fatkasuvayu+linux@gmail.com \
--cc=bzg@altern.org \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).