<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br class="webkit-block-placeholder"></div>Hi Eric,<div><br><div><div>On Jan 23, 2008, at 11:50 PM, Eric Seidel wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I'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.</blockquote><div><br class="webkit-block-placeholder"></div><div>I think there's two separate questions here. First, what formal policy, if any, do we follow for disabling features or removing code. Second, there's the specific question of what to do about foreignObject specifically.</div><div><br class="webkit-block-placeholder"></div><div>Regarding policy:</div><div><br class="webkit-block-placeholder"></div><div>I think there are a few reasons why a feature might be removed or disabled, either permanently or on a vendor's release branch:</div><div><br class="webkit-block-placeholder"></div><div>1) The feature is so destabilizing that it affects testability, and we don't expect it to get fixed soon. This would be a reason to disable code on trunk.</div><div>2) The feature is relatively minorly unstable but has no clear maintainer and may be bitrotting a bit. This might also be a reason (though in this case it would be good to ask around first).</div><div>3) The feature has some significant problem (stability or correctness) that would lead us not to want vendors to ship it in its current state.</div><div><br class="webkit-block-placeholder"></div><div>In case 3, a case could be made for disabling only on appropriate vendor release branches. (On the other hand, if there are many such branches we want to encourage them to do the right thing.) On the other hand, if no one is actively working on the feature, and no one especially objects, it might be ok to disable on trunk.</div><div><br class="webkit-block-placeholder"></div><div>We don't really have a formal policy on this, we just try to use common sense and discussion if there is disagreement.</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div>As for this specific instance:</div><div><br class="webkit-block-placeholder"></div><div>Oliver Hunt suggested disabling foreignObject. I'm not sure which specific problems he was worried about, or which of the above categories they would fall in. Oliver, could you please clarify what the specific problems with foreignObject are. Oliver &amp; Eric, can you please discuss and decide together whether foreignObject should in fact be enabled by trunk?</div><div><br class="webkit-block-placeholder"></div><div>To address some specific questions:</div><br><blockquote type="cite"><div> <div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">I'm interested in discussing the general policy towards new features on trunk and "stabilization"&nbsp;of trunk during release times for various vendors.</span></div><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 "stabilization" concerns. &nbsp;I'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's own branch?</div><div>* Is the current policy that there will be times of "stabilization" 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 "close" trunk to new feature development?</div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>Apple has not requested any formal or de facto stabilization period. Trunk remains open for feature development, porting, performance work, bug fixing, and all the usual good stuff. If we need something more stable than trunk we will use branches as appropriate.</div><br><blockquote type="cite"><div><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">My personal preferences would be:</span></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></blockquote><div><br class="webkit-block-placeholder"></div><div>You didn't finish this sentence, but I assume it meant to raise such features as a possible exception. Currently I think this is the shared understanding of the project.</div><br><blockquote type="cite"><div> <div>* Currently there is no policy to enact a time of "stabilization" 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 "open", unless policies are defined allow for its closure (like perf regressions?).</div></div></blockquote><br></div><div>I think the overly long "stabilization period" on trunk did not work out very well and I don't think we should do it again in the near future.</div><div><br class="webkit-block-placeholder"></div><div>I hope this answers your questions.</div><div><br class="webkit-block-placeholder"></div><div>Regards,</div><div>Maciej</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div></div></body></html>