On 16/02/2011 07:53, Chad wrote:
On Wed, Feb 16, 2011 at 2:12 AM, Ashar Voultoizhashar+wmf@free.fr wrote:
On 14/02/11 15:11, Roan Kattouw wrote:
By the time we deploy 1.17, trunk will already be more than two months ahead. Of course this is because we needed time to stabilize 1.17, which in turn was caused by the amount of new code in it.
What about stopping adding new code in trunk until the branch is stable/live? Most new features / refactoring can probably held by their authors for two or three months.
I've advocated a partial freeze before, but I've been convinced over time that they're generally unhelpful. If a committer has good code to put in, trunk should always be allowing it.
+1
Further arguments on this issue are in [1] under "Don’t freeze the trunk for long periods" where freezing is associated with a significant loss of contribution activity, even beyond the time that the trunk was frozen.
- Markus
[1] http://www.codesimplicity.com/post/open-source-community-simplified/