Hi,

>>>>> If we don't support QT_NO_* officially and let the community fix 
>>>>> problems, we have to disable CONFIG+=qt_minimal on this bot, 
>>>>> because a core builder must be green almost at all times.
>>>>>
>>>> IMO that's sensible. Do we provide guidance for people who want to 
>>>> maintain their own bots where they can test those configurations?
>>>
>>> I agree. Having a core builder that builds a minimal _WebKit_ build 
>>> is something we should strive for, and enabling CONFIG+=qt_minimal 
>>> makes that bot more fragile and less useful for other ports
>>
>> Seconded. The Qt Minimal bot should be minimal WebKit, and that's 
>> already on the edge of what we can reasonably expect non-Qt WebKit 
>> contributors to care about. I'm fine with keeping the QT_NO_* stuff in 
>> place if it's explicitly unsupported and doesn't grow into anything 
>> beyond disabled code blocks here and there.
>
>Second on this, too.
>If we keep the QT_NO* guards in tree we have to document somewhere that this 
>is not officially supported. The minimal bot is otherwise an important one 
>since it is the only one testing the correctness of at least a default set of 
>the >gadzillion WebKit guards.

I would challenge this. I think the problem is that it is a really low bar to 
introduce a new build flag for trunk. We should keep the bar high for not only 
new "WebKit flags" but also for "Qt flags" on the trunk. Allowing a flag 
without a bot is allowing code without auto test. I do not think that having 
flags that almost build is any good.

I would keep the minimal bot configuration as it is or create a new bot for 
CONFIG+=qt_minimal and enforce that every "Qt flags" is also being tested (so 
that at least it builds all the way).

I also agree with Andreas that most QT_NO_* defines should go from WebKit 
trunk. We should start a review process and go trough each and every one of 
them one-by-one. We should consider that some flags might be removed from Qt5 
anyway. 

Laszlo
_______________________________________________
webkit-qt mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt

Reply via email to