As someone sitting on the other side only fixing layout tests this sounds great. The current mode of operation where a merge is landed and others are left to fix the new failures is very disheartening in that we'll make progress only to have a new merge land breaking the progress we made. I now know how a mailman feels!
-Scott 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 -~----------~----~----~----~------~----~------~--~---
