On Tue, Oct 20, 2009 at 1:25 PM, Jeremy Orlow <[email protected]> wrote:
> 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.) > BTW, determining "who makes the most sense" was the goal of this spreadsheet: http://spreadsheets.google.com/a/chromium.org/ccc?key=0AmBv0BNymMh5dHlHZnJDSjR1X0ZzNnRYOFZTVWtvb0E&hl=en. So test breakage can be assigned to someone more familiar with that area of the code (since svn blame doesn't really work for layout tests). Of course, the spreadsheet is only 30% assigned as yet, so whether this will work is TBD (maybe we need an adopt-a-layout-test program). If we decide this is workable, we should put a link to it in the gardening docs. Stephen > 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 >>> >>> >>> >> > > > > -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
