> A better solution would be to have the sheriff (or someone from LTTF) assign the bugs to specific people So how do you figure out who to assign it to?
> with a general rule that such bugs must be fixed within two days (make these bugs the top priority over other tasks). Over security bugs? Over code reviews which other people need (some of which are large and involved)? Over interviews and feedback (if your company is doing this)? Over fixes for a release with a given deadline that may be looming? Over your next round of WebKit gardening? Over fixing a top crasher? :) > This allows for load balancing of bugs, and also makes sure that we have the right people working on any specific bug. As long as one area isn't broken disproportionally or somehow one person isn't assigned bugs disproportionately. > First two days you roll. Next two days you fix layout tests. The net result of 4 days should be 0 (or less!) new layout test failures. Not all WebKit gardening days are equivalent and some will take quite a bit of time to clean up. For example, what happens when someone add structured clones for JSC and we fail the associated layout test? Does the person on that rotation end up getting a new feature to implement? Or if we take Drew's approach, do we make Drew drop what he is doing to implement structured clones, since they are most closely associated with MessagePorts? I don't know the right answer but I don't feel like it is there yet.... > Assign LTTF folks specifically for test clean-up every day. ... appears to separate the action/responsibility dependency. *There already is a separation of action from responsibility*. For example, in yesterday's tragic roll, it shouldn't have been done, but the real action was not done by hclam. It was done by the person who created the v8 patch, and there is no responsibility for the havoc and mess caused by that change. This happens frequently to the gardener. My vote: I lean closest to assigning something like the LTTF folks to clean up recent failures and have rotating duty on to do this for maybe a week or two at a time (even after LTTF is ended). With the ability to pull in/assign/hassle other folks to fix/investigate issues if it is beyond the knowledge of folks on that team. If you have something like the LTTF folks cleaning up, then it seems possible to get more people doing the WebKit gardening. Perhaps, if you are on what I'll call "the LTTF rotations", then you don't have to do the gardening, but you are available to help gardener if they hit some build break that they don't know how to deal with. Dave On Tue, Oct 13, 2009 at 10:53 AM, Drew Wilson <[email protected]> wrote: > I've been thinking quite a bit about this - I agree with Dmitri that the > current Sisyphean approach is unsustainable. > I don't think the right path is to ask the sheriffs to do the cleanup > themselves - for example, a webkit roll that breaks workers in some obscure > way is almost certainly beyond the ability of any random gardener to fix in > two days, especially when there may be multiple bugs. > A better solution would be to have the sheriff (or someone from LTTF) assign > the bugs to specific people, with a general rule that such bugs must be > fixed within two days (make these bugs the top priority over other tasks). > This allows for load balancing of bugs, and also makes sure that we have the > right people working on any specific bug. > -atw > On Tue, Oct 13, 2009 at 10:40 AM, Pam Greene <[email protected]> wrote: >> >> I don't think it's realistic to expect the gardener, or any one person, to >> be able to fix an arbitrary broken layout test in a reasonable period of >> time. That's certainly true for new tests, but even for regressions I often >> can't even tell for sure whether our results are correct, much less what to >> do if they're not. >> It's far more efficient to have the "right" person fix a test. (Of course, >> people should also strive to broaden their knowledge, but there's a limit to >> how much of that one can do in a week.) Never having broken layout tests is >> an excellent goal, but quite frankly I don't think it's one we should >> prioritize so high that we hobble other efforts and burn out developers. >> - Pam >> On Tue, Oct 13, 2009 at 10:31 AM, Dimitri Glazkov <[email protected]> >> wrote: >>> >>> I think we need to change something. I am not sure what -- I have >>> ideas, but -- I would appreciate some collective thinking on this. >>> >>> PROBLEM: We accumulate more test failures via WebKit rolls than we fix >>> with our LTTF effort. This ain't right. >>> >>> ANALYSIS: >>> >>> Ok, WebKit gardening is hard. So is fixing layout tests. You can't >>> call it a successful WebKit roll if it breaks layout tests. But we >>> don't revert WebKit rolls. It's a forward-only thing. And we want to >>> roll quickly, so that we can react to next "big breaker" faster. So >>> we're stuck with roll-now/clean-up-after deal. This sucks, because the >>> "clean-up-after" is rarely fully completed. Which brings failing >>> layout tests, which brings the suffering and spells asymptotic doom to >>> the LTTF effort. >>> >>> POSSIBLE SOLUTIONS: >>> >>> * Extend WebKit gardener's duties to 4 days. First two days you roll. >>> Next two days you fix layout tests. Not file bugs -- actually fix >>> them. The net result of 4 days should be 0 (or less!) new layout test >>> failures. This solution kind of expects the gardener to be part of >>> LTTF, which is not always the case. So it may not seem totally fair. >>> >>> * Assign LTTF folks specifically for test clean-up every day. The idea >>> here is to slant LTTF effort aggressively toward fixing newer >>> failures. This seems nice for the gardeners, but appears to separate >>> the action/responsibility dependency: no matter what you roll, the >>> LTTF elves will fix it. >>> >>> * [ your idea goes here ] >>> >>> TIMELINE: >>> >>> I would like for us to agree on a solution and make the necessary >>> changes to the process today. Tomorrow is a new day, full of >>> surprising changes upstream. >>> >>> :DG< >>> >>> >> >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
