[webkit-dev] ENABLE_FORM_VALIDATION

[Jeremy Orlow]

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
> anyway.
>

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
> opinion.
>

I think we can all agree with that.  :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090713/ee49e15b/attachment.html>