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

[Eric Seidel]

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 <mjs at apple.com> 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
>
>
>