Hi,

I'm still wondering what the best practice is to deal with many updated layout tests in a patch. It seems I must run the layout tests on all effected platforms by myself to ensure a green build after committing the patch, right? This is really difficult to me. Is there a easier way?

Thanks,
Xianzhu

2010/6/2 Xianzhu Wang <phnixwxz@gmail.com>
Hi,

I'm new to webkit development, and I'd like to hear opinions about the problems I met.

Now I'm trying to fix some "old" layout bugs, for example:
  * white space preceding <br> (https://bugs.webkit.org/show_bug.cgi?id=37261)
  * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413)
  * line breaking around some punctuations (https://bugs.webkit.org/show_bug.cgi?id=37698)

Some people have warned me about the difficulty of fixing these bugs, and now I have realized it. Fixing the bugs themselves is not very difficult, for example, only 2 functional lines change can fix the first bug. However, the change will break more than 4000 existing layout tests mostly because trailing spaces preceding <br>s in current expectations of the tests (for example, "PASS " vs "PASS"). I tried to rebaseline all effected layout tests (for now on mac only), and the patch is about 6MB (Sorry I overlooked the "Bigfile" option when I submitted the patch, so I split it into 4 parts).

My questions are:

1. The bugs violate the standards and cause some site compatibility issues. However, because the bugs are old, some web developers might treat them as features and depend on them, so fixing them might break some existing pages. Is there any existing policy about this problem? Are these bugs worth fixing?

2. What's the best practice to deal with a patche containing many updated layout test expectations? Is there a good way to rebaseline the effected tests on all platforms?

Thanks,
Xianzhu