[webkit-changes] [57579] trunk/LayoutTests/platform

[Anton Muhin]

Thanks a lot, David, let's give it a try: closing crbug.com/41455 and
now we have WebKit bug 37577 :)

yours,
anton.

On Wed, Apr 14, 2010 at 3:38 PM, David Levin <levin at chromium.org> wrote:
>
>
> On Wed, Apr 14, 2010 at 8:01 AM, Anton Muhin <antonm at chromium.org> wrote:
>>
>> David, thanks lot.
>>
>> And as I am going to submit another patch to fix the rest of layout
>> tests, I'd esp. appreciate your and others advice.
>
> fwiw, this is all of course my opinion, but I agree with them. :)
>
>>
>> On Wed, Apr 14, 2010 at 6:53 PM, David Levin <levin at chromium.org> wrote:
>> > I know this is pretty new since folks on the chromium team are getting
>> > use
>> > to having results in WK now, so you're helping trail blaze. With that in
>> > mind, I think it would be good to mention a few things early on before
>> > they
>> > become habits for chromium folks.
>> > 1. Ideally even changes of this type would still be looked over at least
>> > by
>> > someone else. (When I did a pixel test rebaseline, things looked funny
>> > so I
>> > contacted the patch author to confirm and it turned out to be a
>> > regression
>> > introduced by the patch.)
>>
>> I agree with you.  That's exactly why I bothered chrome-dev and failed
>> p0 bug.  The problems are 1) I don't know who from Chromium team
>> should review those changes, 2) chances are high this person is asleep
>> and would be blocked for the whole day.
>
> I see. In my case I picked someone random for a sanity check but it seems
> that you are going for a more thorough approach. We are indeed still
> figuring this out.
>
>
>>
>> So I decided to make it roll forward, but keep all the references in
>> the bug itself and thus when expert shows up s/he could revert/adjust
>> the things I committed.
>>
>> > 2. Regardless even if it is not reviewed, there should still be a
>> > descriptive changelog (and commit message) for the change, and of course
>> > a
>> > WebKit bug seems more appropriate than a chromium bug.
>> > I believe in this case, it would at a minimum say something like:
>> >   "Adding test results for chromium due to new test additions done in
>> > r#"
>> > or
>> >   "Changing test results for chromium due to the svg behavior change
>> > done in
>> > r#"
>>
>> Ok, I'll make description more wordy.
>
> While that will be the end result, the goal is above making it more
> descriptive so one can quickly read the changelog/commit entry and
> understand what this change is about and why it is being done.
>
>>
>>  Regarding where to file it---I
>> thought that as this is only Chromium related it should go to Chromium
>> bug tracking, but surely, could change the things.
>
> I understand the ambiguity here... but even chromium only changes that go
> into the webkit respository are done as bugzilla bugs, so it makes sense to
> me to apply the same thing here.
>
>>
>> Given that I already filed a bug for next expectations update against
>> Chromium, what would you recommend:
>>
>> 1) close Chromium bug and open WebKit bug;
>
> Yes.
>
>>
>> 2) let Chromium bug exist and open WebKit bug which references Chromium
>> bug;
>> 3) something else.
>>
>> And I'd volunteer to update Wiki after we settle all those things down.
>>
>> Thanks again and waiting for your reply (and we have almost .5hr for
>> canary cycle to finish before I could spoil something new :)
>>
>> yours,
>> anton.
>>
>> > Thanks much,
>> > dave
>> > On Wed, Apr 14, 2010 at 7:12 AM, <antonm at chromium.org> wrote:
>> >>
>> >> Revision 57579 Author antonm at chromium.org Date 2010-04-14 07:12:09
>> >> -0700
>> >> (Wed, 14 Apr 2010)
>> >>
>> >> Log Message
>> >>
>> >> Not reviewed.
>> >>
>> >> BUG=http://code.google.com/p/chromium/issues/detail?id=41450
>> >>
>