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
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
Right. Ultimately, we need to have a buildbot visible on
build.webkit.orgthat reports layout test failures to others in the
webkit community. Then,
we can pester the webkit contributor to help fix the problems they caused.
At the very least, we'll have the big advantage of knowing precisely
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
I'm ok with saying that you do the merge one day and have another day to
cleanup layout test issues. Once we're not merging anymore though, I think
we should just have 1-2 people oncall for 1 week at a time to keep the
webkit(webkit.org) build green and to pull a new revision at least once a
day
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 da...@chromium.org wrote:
Right. I just mean that the merger should take care to ensure that all of
the easy
Added layout-test cleanup steps to the instructions.
- Pam
On Wed, Mar 4, 2009 at 6:08 PM, David Levin le...@chromium.org 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
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
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
On Thu, Jan 15, 2009 at 1:20 PM, Pam Greene p...@chromium.org wrote:
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
Generally +1, except I just imagined the situation where the merger
collides with the fixer. So maybe no overlapping, just do the merge
every other day?
:DG
On Thu, Jan 15, 2009 at 1:31 PM, Brett Wilson bre...@chromium.org wrote:
On Thu, Jan 15, 2009 at 1:20 PM, Pam Greene p...@chromium.org
On Thu, Jan 15, 2009 at 1:31 PM, Brett Wilson bre...@chromium.org wrote:
On Thu, Jan 15, 2009 at 1:20 PM, Pam Greene p...@chromium.org wrote:
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
I definitely get that a merge is no trivial amount of work, and my
expectations are probably unrealistic without more than one person
working on a merge at a time. I was hoping for a magic bullet, but
those are only in movies:(
-Scott
PS If anyone not doing merges feels like the people doing
This is veering wildly off-topic, but I think the key to solving merge
regressions is in moving to an integration model. With the integration
model, we can integrate one WebKit changeset at a time, and clearly
identify the regressions. This would go a long way in identifying the
cause and
14 matches
Mail list logo
