On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote:
On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt <[email protected]> wrote:
I agree. We should formalize this as policy too in my opinion.
Maybe something time-based, e.g., if you have an implementation of a
new Web technology that is going to take > (1month?) to implement,
then the feature should be landed inside ENABLE ifdefs (that can
then be removed when the feature is sufficiently far along).
For Chromium this kind of time frame can be problematic, since
there's pretty much no guarantee of when a WebKit trunk build could
be shipped as (eventually) a stable Chromium/Google Chrome release.
Even having an incomplete feature in the tree a few days can result
in the incomplete feature getting shipped to web authors.
The way to ship "ToT" (in my opinion) is to cut a branch, watch ToT
for any regressions from recent work, merge those fixes into the
branch, and then turn off anything that is "in-progress" on the
branch. Expecting ToT to actually be shippable all the time is not
very practical. Realistically people will always be causing
occasional regressions from bug fixes and feature work. Branches are
the way to stabilize from some known point.
dave
([email protected])
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
