On Mon, Aug 24, 2009 at 10:37 AM, Pam Greene <p...@chromium.org> wrote:
>
> On Sat, Aug 22, 2009 at 4:29 PM, Jeremy Orlow <jor...@chromium.org> wrote:
>
>> On Sat, Aug 22, 2009 at 4:00 PM, Peter Kasting <pkast...@chromium.org>wrote:
>>
>>> On Fri, Aug 21, 2009 at 8:07 PM, Jeremy Orlow <jor...@chromium.org>wrote:
>>>
>> There are different reasons for failing. A layout test could be failing
>>>> because of a known bug and then start failing in a different way (later)
>>>> due
>>>> to a regression. When a bug fails in a new way, it's worth taking a quick
>>>> look, I think.
>>>>
>>>
>>> Why? Unless the earlier failure has been fixed we can't rebaseline the
>>> test. (I ran into a number of tests like this when doing my rebaselining
>>> pass.) What is the point of looking again?
>>>
>>
>> In case the new failure is more serious than the earlier one.
>>
>
> True. But I don't think this will happen often, and I'd rather devote the
> time to fixing the tests.
>
The end goal is to be in a state where we have near zero failing tests that
are not for unimplemented features. And new failures from the merge get
addressed within a week.
Once we're at that point, would this new infrastructure be useful? I
completely support infrastructure that sustainably supports us being at near
zero failing tests (e.g. the rebaseline tool). All infrastructure/process
has a maintenance cost though.
Ojan
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
