Thank you for your clear and informative reply! Oliver and I have discussed foreignObject, he has decided to re-enable it on trunk. We'll work to make sure any remaining issues are resolved.
I'm glad to have more of this rational "down on paper" in the open. -eric On Mon, Feb 4, 2008 at 3:42 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > > Hi Eric, > > > On Jan 23, 2008, at 11:50 PM, Eric Seidel wrote: > I'd like to get some clarification from other members of the WebKit project, > regarding the policy regarding having features on/off on trunk. > Specifically Apple folks, since they are the largest single vendor actively > contributing to the WebKit Open Source Project. > > 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. > > Regarding policy: > > I think there are a few reasons why a feature might be removed or disabled, > either permanently or on a vendor's release branch: > > 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. > 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). > 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. > > 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. > > We don't really have a formal policy on this, we just try to use common > sense and discussion if there is disagreement. > > > As for this specific instance: > > 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 & Eric, can you please discuss and decide together > whether foreignObject should in fact be enabled by trunk? > > To address some specific questions: > > > > I'm interested in discussing the general policy towards new features on > trunk and "stabilization" of trunk during release times for various vendors. > > This was prompted by my recent discovery that SVG_FOREIGN_OBJECT feature had > been turned off. I assume for "stabilization" concerns. I've filed a bug: > http://bugs.webkit.org/show_bug.cgi?id=16991 about that specific case. > > > * Is trunk the advised location for all feature development? At what point > should a feature be moved off onto it's own branch? > * 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? > > * 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? > > 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. > > > My personal preferences would be: > * Trunk is the location for all feature development. Large features which > would disturb other development (introduce more than N p1 bugs, break the > build, break patches repeatedly, etc.) > > 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. > > > > * 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. Stabilization periods 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*). > * I know of no such procedure, but I can see rational for creating one. > Without one, my default would be to leave trunk always "open", unless > policies are defined allow for its closure (like perf regressions?). > 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. > > I hope this answers your questions. > > Regards, > Maciej > > > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
