[webkit-dev] ENABLE_FORM_VALIDATION

[Darin Fisher]

On Mon, Jul 13, 2009 at 2:55 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jul 13, 2009, at 11:57 AM, David Hyatt 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.  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'm more or less with Hyatt on this one. I think it would be process
> overkill to require ifdef for every feature that has more than one
> implementation step. A month sounds like about the right time scale where a
> switch is useful. One other thing to keep in mind: sometimes an incomplete
> implementation of a feature may still be a state that's useful to ship. I'm
> hoping people can exercise good judgment here and ping the list when in
> doubt.
>
> Regards,
> Maciej
>
>

This small interval rule-of-thumb idea sounds pretty good, but I still wish
it didn't put the burden on the guy doing the branch to figure out what is
or isn't incomplete about a particular snapshot of WebKit.  That guy might
not be savy enough to know what he should be concerned about.

The developer of the new feature, on the other hand, is the expert and
should be in the best position to know when their work is shippable.  It
seems like there should be a low-cost way for such developers to flag a
feature as incomplete and then clear that flag when it becomes safe to ship
the feature.  Afterall, it would seem to be in that developer's best
interest to not have their new work shipped prematurely (thus causing its
adoption to be stunted by incompatibility issues).

Adding an ENABLE flag doesn't seem like that great of a tax to me.

Alternatively, perhaps there could be more communication from the developer
landing an incomplete feature?  A simple heads-up to the list might be
enough.  "Hey, I just landed the first part of HTML5 foo bar.  Right now,
everything is just stubbed out, but I will be landing the implementation in
the next few days."

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090713/cb2782cd/attachment.html>