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 addressing the issue.
Unfortunately, currently we have engineers fixing layout tests and making changes to our WebKit fork, which makes integration model ... complicated. What if we go with an integration->merge model, which works as follows: 1) we have a separate WebKit git repository (hosted on someone's machine even), which has a branch with all of our changes applied as one (or more) patch. 2) you pull WebKit changes, rebase (in other words, re-apply our change patches), see if the changes broke anything. 3) if they did, identify the changeset that breaks stuff by using git bisect (nifty stuff, I might say), then mark it in text_fixable and file a bug 4) merge integrated changes into main svn repository. ... or something like that? Somebody take this idea and flesh it out to make it excellent! :) :DG< On Thu, Jan 15, 2009 at 2:51 PM, Scott Violet <[email protected]> wrote: > > 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 merges should do >> more, please volunteer to do a merge so at least you'll know what it is like >> -- Sorry Scott but I'm looking at you :) >> >> On Thu, Jan 15, 2009 at 2:26 PM, Pam Greene <[email protected]> wrote: >>> >>> On Thu, Jan 15, 2009 at 1:31 PM, Brett Wilson <[email protected]> wrote: >>>> >>>> On Thu, Jan 15, 2009 at 1:20 PM, Pam Greene <[email protected]> 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 fix them in one day). So perhaps "clean up" in this context means >>>> > "re-baseline if that's all it needs, and file individual bugs on >>>> > specific >>>> > people for bigger brokenness". >>>> >>>> I think our tendency to file bugs and forget about it is part of the >>>> problem. I am at least as guilty as anybody else. I think the merger >>>> should have the responsibility to get their regressions fixed. They >>>> will have to talk with some other people to get input. If they aren't >>>> the right person to fix a problem, it should be their responsibility >>>> as part of the cleanup to make sure that the right person has been >>>> assigned to it and is actually working on it. >>> >>> Taking responsibility, check. Making sure someone is assigned, check. >>> Fixing tricky regressions yourself may not be the most efficient use of >>> time, and would be a strong deterrent to volunteer for a merge. Merging >>> isn't much fun; fixing layout tests isn't much fun. Let's spread the pain >>> where suitable, rather than piling it all on the person who volunteers for >>> one part. >>> In fact, I'd ask the merger to fix the "easy" problems (tests changed, new >>> tests need baselines) before committing the merge. >>> >>>> >>>> When people are assigned merge bugs, they should be treated as >>>> important regressions and prioritized over other work. We currently >>>> had a whole lot of layout tests bugs filed that are getting no love. >>>> The only way to not keep getting behind is to be much more proactive. >>> >>> Absolutely. >>> >>>> >>>> > Also, to clarify, are you proposing that we only merge every other day, >>>> > or >>>> > that we have two people assigned each day: one to merge and one to >>>> > clean up >>>> > the previous day's layout-test breakage? If the latter, we could also >>>> > split >>>> > the job in the other direction, and have one person merging two days in >>>> > a >>>> > row and one fixing up the test list both days. I could imagine >>>> > people's >>>> > tastes running more to one job or the other, and we don't really care >>>> > who >>>> > does what as long as it gets done. >>>> >>>> I'm proposing overlapping so we merge every day. I think there is an >>>> advantage in having the same person who did the merge do the fixing. >>>> This hopefully also makes the merge less tedious since you have >>>> different tasks your two days. >>> >>> Sounds fine. People can always trade if they want. >>> - Pam >>> >>>> >>>> Brett >>>> >>>> >>> >>> >>> >> >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
