The process I was picturing is that we'd have a WebKit sheriff. That person would be in charge of keeping the build with latest webkit green and updating the webkit revision we pull once a day. If someone else needs a newer webkit revision (e.g. something they just committed), they can work with the WebKit sherriff to pull it in. But basically, it would be that person's job to either rebaseline failing tests or add them to the fixable list and assign them to someone to fix. Ojan
On Wed, Mar 4, 2009 at 5:01 PM, David Levin <[email protected]> wrote: > Yes, so what would be the process then? (Will we still have "mergers" > whose job is mostly to handle new and modified layout tests?) > > On Wed, Mar 4, 2009 at 4:58 PM, Ojan Vafai <[email protected]> wrote: > >> 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 -~----------~----~----~----~------~----~------~--~---
