Even once pulling in a new webkit is as simple as changing a revision number in DEPS, we'll still have new and modified layout tests that we'll need to deal with.
On Wed, Mar 4, 2009 at 4:44 PM, David Levin <[email protected]> wrote: > Aren't we trying to get rid of the merge process (soon-ish)? > If so, how would layout tests get fixed at that point? > > Dave > > On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher <[email protected]> wrote: > >> I think the merger should be responsible for ensuring that any layout test >> fallout from the merge gets resolved. This doesn't mean necessary fixing >> everything, but rather it can be mean reaching out to others for help. >> I think the merger has to have incentive not to create a big mess with the >> merge and to also make sure the job gets done completely :-) >> >> -Darin >> >> >> On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet <[email protected]> wrote: >> >>> >>> If we are ever to keep up to date with layout tests we need to come to >>> a consensus on this. Here's the current set of proposals: >>> >>> 1. The merge becomes a two day activity. First day is merge, second >>> day is fixing any failing layout tests. >>> 2. We tag team people: first person does merge, next day another >>> person fixes any failing layout tests. >>> 3. One person for merge (like we do now), and failures are handled by >>> owners of the layout tests. This assumes we can identify owners for >>> buckets of layout tests so that folks know they are on the spot for a >>> failing test. >>> >>> At this point we only care about regressions since 1.0, but that'll >>> change soon. >>> >>> Can we make a decision on this at next weeks WebKit meeting? >>> >>> -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 -~----------~----~----~----~------~----~------~--~---
