Added layout-test cleanup steps to the instructions. - Pam
On Wed, Mar 4, 2009 at 6:08 PM, David Levin <[email protected]> wrote: > I know that I haven't filed chromium bugs for layout test failures in the > past because it isn't in the instructions (I thought adding the the > tests_fixable was sufficient.) > > http://dev.chromium.org/developers/how-tos/webkit-merge-1 > > > Though I do usually have at least a partial 3rd day of items for clean up: > upstreaming, some times filing bugs for new reliability crashes, etc. > Dave > > > On Wed, Mar 4, 2009 at 5:30 PM, Pam Greene <[email protected]> wrote: > >> I'm not sure how closely that's followed. Me, I did merges Monday and >> Tuesday, and layout-test cleanup (baselines and bugs) today. >> - Pam >> >> >> On Wed, Mar 4, 2009 at 5:10 PM, Darin Fisher <[email protected]> wrote: >> >>> Right. I just mean that the merger should take care to ensure that all >>> of the easy "fixes" are done and that the rest are accounted for somehow, >>> probably via regression bugs. If that's the current process, then great. >>> It just sounded like it wasn't. >>> -Darin >>> >>> >>> >>> On Wed, Mar 4, 2009 at 4:51 PM, Pam Greene <[email protected]> wrote: >>> >>>> Define "resolved". Is filing and assigning a bug sufficient? It's not >>>> efficient to have whoever volunteers to do a merge personally pester people >>>> to fix the resulting test errors forever after. >>>> Whatever we do, we're going to have broken layout tests after a merge. >>>> Easy "fixes" -- re-baselining the ones that are actually all right, and >>>> filing specific bugs for the rest -- are definitely part of the merge task. >>>> But we don't want to put too much blame on the messenger: if a bunch of >>>> tests really break, or new tests don't pass, it's hardly the fault of the >>>> person who happened to bring the changes in. >>>> >>>> - Pam >>>> >>>> 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 -~----------~----~----~----~------~----~------~--~---
