jorlow at chromium.org
Mon Jul 13 12:12:05 PDT 2009
On Mon, Jul 13, 2009 at 11:57 AM, David Hyatt <hyatt at apple.com> wrote:
> On Jul 13, 2009, at 1:52 PM, Jeremy Orlow wrote:
> On Mon, Jul 13, 2009 at 11:40 AM, David Hyatt <hyatt at apple.com> wrote:
>> On Jul 13, 2009, at 12:52 PM, Peter Kasting wrote:
>> On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt <hyatt at apple.com> 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.
> I agree, but I also agree with Peter's heuristic for when things should be
> behind a flag. Regressions can always happen, but if you're knowingly
> introducing something that's half-baked it really seems like it should be
> behind a flag.
> I agree with that. I'm just asserting that some reasonable time limit
> before requiring ifdefs is ok. If a feature only takes 1-2 weeks to land, I
> think it's total overkill to put it inside an ifdef. Any cut branch should
> take long enough to stabilize that it could merge the rest of the feature in
Hm. Now that I think about it, I'm mixing up breaking existing behavior and
adding new features which are in flux. In the former case, it should always
be behind a flag, right? But yeah, for the latter case, I guess 1-2 weeks
seems reasonable to me.
> If you're ever cutting a branch off ToT and shipping it as a full-blown
> release with less than 2 weeks turnaround, you're doing it wrong in my
I think we can all agree with that. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev