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 -~----------~----~----~----~------~----~------~--~---
