[webkit-dev] Trunk policy regarding new features and stabilization

[Maciej Stachowiak]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080204/589f9804/attachment.html