I don't think this is a good idea. With respect to two days of merging, it was a good thing (for me). For one thing, the first day was an absolute pain and it took me well into the second day to get it checked in. On the other hand, the second merge was a breeze by comparison (no added/remove files, no method name changes needed in own code, etc.) It took me a least three days. After merging various unit test failures got blaimed on the merge so I tracked down those failures and submitted fixes (and they weren't the fault of the merge but instead due to a unit test re-sorting that happened to occur at the same time.)
In addition, after the merge, you need to upstream the changes that you had to do back to webkit. Not too hard but it adds time. With respect to layout test, we could do two things: 1. Have a layout test fixers that rotate like merges. That seems like what Brett is proposing anyway but tacking it on to the people doing the merges. 2. Have folks who are familiar with the areas look at the breaks. If the fix is easy, then it should be fast to rebaseline, etc. (If it isn't easy, then the people doing merges, aren't going to do it any faster.) If you had stuck me on fixing layout tests after the merge, I would have spent a day on it and likely accomplished not much (nothing) due to my lack of familiarity with Chromium code (sorry, I mostly work on WebKit). Dave 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 -~----------~----~----~----~------~----~------~--~---
