Re: [webkit-dev] Trunk policy regarding new features and stabilization
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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Trunk policy regarding new features and stabilization
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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Trunk policy regarding new features and stabilization
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'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? 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.) * 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?). Looking forward to your comments. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
