When fixing layout tests only means re-baselining, that's easy. But sometimes they break (or new ones fail) for deeper reasons, and the person doing the merge may not be the right one to make the fix (or may not be able to fix them in one day). So perhaps "clean up" in this context means "re-baseline if that's all it needs, and file individual bugs on specific people for bigger brokenness". Also, to clarify, are you proposing that we only merge every other day, or that we have two people assigned each day: one to merge and one to clean up the previous day's layout-test breakage? If the latter, we could also split the job in the other direction, and have one person merging two days in a row and one fixing up the test list both days. I could imagine people's tastes running more to one job or the other, and we don't really care who does what as long as it gets done.
- Pam On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson <[email protected]> wrote: > > 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
