I&#39;d like to get some clarification from other members of the WebKit project, regarding the policy regarding having features on/off on trunk. &nbsp;Specifically Apple folks, since they are the largest single vendor actively contributing to the WebKit Open Source Project.<div>
<div><br class="webkit-block-placeholder"></div><div><div>I&#39;m interested in discussing the general policy towards new features on trunk and &quot;stabilization&quot;&nbsp;of trunk during release times for various vendors.<br>
</div><div><br></div></div><div>This was prompted by my recent discovery that SVG_FOREIGN_OBJECT feature had been turned off. &nbsp;I assume for &quot;stabilization&quot; concerns. &nbsp;I&#39;ve filed a bug:&nbsp;<a href="http://bugs.webkit.org/show_bug.cgi?id=16991">http://bugs.webkit.org/show_bug.cgi?id=16991</a>&nbsp;about that specific case.</div>
<div><br></div><div><div>* Is trunk the advised location for all feature development? &nbsp;At what point should a feature be moved off onto it&#39;s own branch?</div><div>* Is the current policy that there will be times of &quot;stabilization&quot; for the trunk, to match with a certain vendor or set of vendors release cycles?<br>
</div></div><div>* If a vendor (or group of contributers) wishes to ship from trunk, is there a procedure by which they can &quot;close&quot; trunk to new feature development?</div><div><br class="webkit-block-placeholder">
</div><div>My personal preferences would be:</div><div>* Trunk is the location for all feature development. &nbsp;Large features which would disturb other development (introduce more than N p1 bugs, break the build, break patches repeatedly, etc.)</div>
<div>* Currently there is no policy to enact a time of &quot;stabilization&quot; for trunk, however I think such could make sense if there was a way for enough contributers to agree. &nbsp;Stabilization periods&nbsp;should last no more than a month or two, during which time, all feature work should continue on a feature branch (similar to last summer, except *not nearly so long*).</div>
<div>* I know of no such procedure, but I can see rational for creating one. &nbsp;Without one, my default would be to leave trunk always &quot;open&quot;, unless policies are defined allow for its closure (like perf regressions?).</div>
<div><br class="webkit-block-placeholder"></div><div>Looking forward to your comments.</div><div><br class="webkit-block-placeholder"></div><div>-eric</div></div>