On 11/12/2009 09:17 AM, John Plevyak wrote:
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.
Mozilla had a strict RTC policy always, which I personally found
somewhat difficult to work with. Back then, we had no such tools as git,
so most of us ended up sitting with many, many patchsets uncomitted,
forcing us to have copy after copy of the repo ... Mozilla has since
switched to Mercurial (hg), which helps, but I still think their process
was too restrictive.
One thing however that I did like was that trunk could be closed down
for a few days for various reasons, e.g.
1) Cutting a "stable" release branch (as John mentions with OpenBSD),
but this would generally not be very long.
2) Shepherding a development branch to trunk. Large changes would
generally be developed on a branch, although, not as much as I would
have preferred, and we'd close trunk to merge those back.
My vote would be a CTR policy for trunk, but reviews obviously allowed
if a committer so wishes (e.g. to verify something). The trunk rules
should also have the addition that larger changes should be done on a
Subversion branch. In preparation for making releases, we'd freeze trunk
(effectively turn it into RTC). And as has been suggested already, all
release branches are implicitly RTC.
I still think all commits should be associated with a bug, for easier
tracking (but, I know that's not the httpd way).
-- Leif
