I'm currently doing a 2-day merge rotation.As part of this, various
layout tests are regressing or getting added that I'm inserting into
the tests_fixable list.
But, like every other layout test fixer, after my merges are done,
I'll finally go back to my old work and not think about it any more.
This is how we get a monotonically increasing list of broken tests at
the end of the tests fixable. I'm pretty certain this happens faster
than the tests are getting fixed because nobody wants to fix them. I'm
sort of tempted to just fix the ones my merge broke now, but that will
put me behind for my next merge, so I don't do that.
I propose a different rotation schedule for WebKit merges. You would
do one day of merges, and the next day you would have to clean up all
the regressed and new layout tests your merge introduced. The layout
tests usually aren't that hard, so it normally wouldn't take the whole
day. This way we can be in a good steady state of WebKit merges. It
should also have a big advantage for fixing the broken tests since the
things that changed, the build numbers involved, etc. are still fresh
in the merger's head, and it won't be like approaching a random layout
test from the list with no context.
The disadvantage of doing this is that we have to find people to do
the merges faster (we should probably formalize the schedule), and
you'll lose some advantage the second day of having all the
instructions and gotchas of the merge fresh in your mind. I was
thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but
that seems too heavyweight for the people volunteering to do this.
Anybody have any comments?
Brett
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
