On Tue, Oct 20, 2009 at 10:19 AM, David Levin <[email protected]> wrote:
> That sounds like a reasonable policy. Hmm...I thought this was the policy. I guess not? :-) > There is the current idea of figuring out something about the crash before > filing a bug, which clashes with this idea. > What text would you add to > http://dev.chromium.org/developers/how-tos/webkit-merge-1 to tell how to > deal with these? Here's one idea (add it in red?): > > If you must roll WebKit DEPS and pick up new crashers, you should enter an > individual bug for each new crasher immediately and make it P0. > > > Then what about assigning. Does it go to the unlucky webkit gardener who > happened to have the duty that day? (If they have another day of gardening, > then these bug linger.) > If the gardener has time, sure. If not, maybe assign it to whomever makes the most sense. And, when there's no obvious candidate, they can draft someone. (In general, I think we should empower gardeners to draft people when there are lots of high prioirity items stacking up and/or we get really behind ToT.) On Tue, Oct 20, 2009 at 9:23 AM, Jeremy Orlow <[email protected]> wrote: > >> Today I noticed a bunch of recently added CRASH test expectations for >> layout tests. I know that we sometimes have to roll in a crasher or two, >> but aren't we supposed to be filing p0-p1, dev channel release blockers at >> least until we can prove the crash is not exploitable in the browser and >> ideally not before the crash is fixed?? >> Btw: >> $ grep CRASH test_expectations.txt | egrep -v '^//' | wc -l >> 56 >> >> And many of them are fairly new. >> >> J >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
