[chromium-dev] Re: Crashing layout tests
On Tue, Oct 20, 2009 at 1:25 PM, Jeremy Orlow wrote: > On Tue, Oct 20, 2009 at 10:19 AM, David Levin 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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Crashing layout tests
What do you mean by "that"? Updating the doc? Btw, the original reason why I asked was that I wanted to confirm we all agreed with this policy. I guess it sounds like everyone does and the only question is making sure everyone starts following it? J On Tue, Oct 20, 2009 at 11:28 AM, Dimitri Glazkov wrote: > Yaar and I discussed making changes to that effect last week, he's > working on that. > > :DG< > > On Tue, Oct 20, 2009 at 10:33 AM, David Levin wrote: > > If it isn't written > > here http://dev.chromium.org/developers/how-tos/webkit-merge-1, then > (imo) > > it isn't policy for gardener. :) Given that not everyone is in the same > > place, if it isn't written in the standard place, how will folks know? > > Even then, if you add something new, it would be nice to tell folks b/c > I'm > > sure not everyone checks that every time they start gardening. > > dave > > On Tue, Oct 20, 2009 at 10:25 AM, Jeremy Orlow > wrote: > >> > >> On Tue, Oct 20, 2009 at 10:19 AM, David Levin 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 > >>> 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Crashing layout tests
Yaar and I discussed making changes to that effect last week, he's working on that. :DG< On Tue, Oct 20, 2009 at 10:33 AM, David Levin wrote: > If it isn't written > here http://dev.chromium.org/developers/how-tos/webkit-merge-1, then (imo) > it isn't policy for gardener. :) Given that not everyone is in the same > place, if it isn't written in the standard place, how will folks know? > Even then, if you add something new, it would be nice to tell folks b/c I'm > sure not everyone checks that every time they start gardening. > dave > On Tue, Oct 20, 2009 at 10:25 AM, Jeremy Orlow wrote: >> >> On Tue, Oct 20, 2009 at 10:19 AM, David Levin 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 >>> 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Crashing layout tests
If it isn't written here http://dev.chromium.org/developers/how-tos/webkit-merge-1, then (imo) it isn't policy for gardener. :) Given that not everyone is in the same place, if it isn't written in the standard place, how will folks know? Even then, if you add something new, it would be nice to tell folks b/c I'm sure not everyone checks that every time they start gardening. dave On Tue, Oct 20, 2009 at 10:25 AM, Jeremy Orlow wrote: > On Tue, Oct 20, 2009 at 10:19 AM, David Levin 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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Crashing layout tests
On Tue, Oct 20, 2009 at 10:19 AM, David Levin 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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
