[webkit-dev] ENABLE_FORM_VALIDATION

Darin Fisher darin at chromium.org
Mon Jul 13 16:08:12 PDT 2009


On Mon, Jul 13, 2009 at 3:17 PM, David Hyatt <hyatt at apple.com> wrote:

> On Jul 13, 2009, at 5:02 PM, Darin Fisher wrote:
>
>  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.
>>
>>
> That's exactly who the burden should be on though.  ToT is a development
> tree.


ToT is a development tree, but....  it follows a "trunk stable" development
model, enforced by layout tests.  What layout tests don't reflect is the
incompleteness of the features tested.



> It's the organization shipping their product that should be working to
> determine when their product is shippable.
>

I agree in principle.  My point was that the original developer is the
expert on their feature.  To an embedder of WebKit, a feature may seem
mostly complete, passing all of the existing layout tests, and yet... it
might be considered a shame to ship it in that state.  It is easy to miss
subtle details, even when reviewed by someone expert in the field.

It seems like it hurts WebKit compat to have products out there with
incomplete implementations of new APIs, so there are incentives not only for
the organization shipping a WebKit-based product but also for all involved
with WebKit.



>
>
>  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.
>>
>>
> I think it would be a great annoyance for very small features.  I also
> expect that people would sit on their feature until it was completely done
> and stop properly staging work in order to avoid adding such short-lived
> ifdefs to the project.  That would just make the patch review process more
> painful, and make it harder to track down individual bugs caused by the lack
> of incremental landings.


I'm not sure I follow...  A particular port could choose to enable the flag
from day one.  Nothing changes if you are the developer of both the feature
and the port that has the flag enabled from day one.  Other ports could
opt-in later, or be forced to opt-in once the feature is complete and the
ENABLE flag is removed.



>
>
>  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."
>>
>>
> I think that's an excellent idea.  We could try to do that more via checkin
> comments and ChangeLogs also.
>


Thanks!

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


More information about the webkit-dev mailing list