And then you have a short feature lock when trunk goes RTC before it becomes
the new stable. Everyone wants that to be short because it is a pain so
they
try to ensure trunk is stable. That is like the 6 month + feature lock
window
that the OpenBSD team uses. They also make the feature lock date a surprise
to encourage early checkin.
Nick Kew wrote:
Dossy Shiobara wrote:
On 11/12/09 9:51 AM, Leif Hedstrom wrote:
Something to consider... I can see both sides of RTC vs CTR. Thoughts?
This is where a good DVCS helps: developers happily work in their own
branches, committing as they go. Then, after review, the changes can
get merged into the main-line trunk/HEAD.
In projects where reliability and stability are valued over feature
count, RTC is the way to go. In projects where rapid development and
addition of features are valued over short-term reliability and
stability, CTR is preferred.
Good points, and I'm sure we'll have a full-blown DVCS sometime in
the not-too-distant future.
I like the httpd model: /trunk/ is CTR, while stable branches are RTC.
So my brainwave can go in trunk, then get reviewed by fellow devs -
just in case it was really a brainfart - before hitting the users.
All backport proposals go in a STATUS file. I find that useful in
that it relieves the burden of watching every commit, and provides
a focus for what really needs reviewing.
