From: Bastien <bzg@altern.org>
To: Suvayu Ali <fatkasuvayu+linux@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Thanks for Lilypond export (and minor comments)
Date: Mon, 11 Jul 2011 18:50:13 +0200 [thread overview]
Message-ID: <87wrfosqwq.fsf@gnu.org> (raw)
In-Reply-To: <20110710185058.2e29b13d@kuru.homelinux.net> (Suvayu Ali's message of "Sun, 10 Jul 2011 18:50:58 +0200")
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
next prev parent reply other threads:[~2011-07-11 16:56 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
2011-07-11 16:50 ` Bastien [this message]
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=87wrfosqwq.fsf@gnu.org \
--to=bzg@altern.org \
--cc=emacs-orgmode@gnu.org \
--cc=fatkasuvayu+linux@gmail.com \
/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).