[webkit-dev] ENABLE_FORM_VALIDATION

[Maciej Stachowiak]

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

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