That works great for big changes, but it does add overhead to small
fixes, and there is some
inevitable instability even for reviewed changes when they go out to a
wider audience. Even
with reviews the trunk will still require a feature lock period and
wider testing before tagging
a release. Also, the idea of limiting committers is that they are
supposed to be the reviews.
For RTC during lock you would want multiple reviewers.
Dossy Shiobara wrote:
On 11/12/09 11: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.
Right ... when there's a lot of commiter activity, that "feature freeze"
period where things become RTC (anyway) can become really protracted.
Admitting that this is a reality, why not just operate in RTC always
which lets you push out releases "on demand" - or, discourage commits to
trunk/HEAD and instead have developers commit to their own personal
branch which lets developers share changes and use the VCS, but ensures
that trunk/HEAD from which releases are branched stays stable and
reliable as changes only get merged from branches to trunk after review.
