As one of the primary people sheriffing alerts, I have found that we get
decisions made much faster as a result of this policy. I would be
interested to hear if others have differing opinions as I could be seeing
this with tunnel vision.
-Joel
On Fri, Mar 27, 2015 at 4:34 PM, Lawrence Mandel
w
Old thread but now that we're 3 months into 2015, has this new policy been
effective at getting perf regressions fixed or at least deliberately
accepted?
Lawrence
On Fri, Dec 19, 2014 at 1:33 PM, wrote:
> Great questions folks.
>
> :bsmedberg has answered the questions quite well, let me elabor
Great questions folks.
:bsmedberg has answered the questions quite well, let me elaborate:
Before a bug can be marked as resolved:fixed we need to verify the regression
is actually fixed. In many cases we will fix a large portion of the regression
and accept the small remainder.
We do keep tra
On 12/19/2014 10:05 AM, Ehsan Akhgari wrote:
Acceptable outcomes:
* A promise to attempt a fix at the bug is agreed upon, the bug is
assigned to someone and put in a queue.
How do we ensure that the follow-up bug actually does get fixed and it
fixes the regression completely?
Avi/Vladan
This looks good overall. Two questions though:
On 2014-12-18 6:47 AM, jmaher wrote:
Mozilla - 2015 Talos performance regression policy
Over the last year and a half the Talos tests have been rewritten to be more
useful and meaningful. This means we need to take them seriously and cannot
jus
Is the Talos sherriff going to confirm that the backout actually fixed the
regression? If it didn't, can we reland?
On Thu, Dec 18, 2014 at 6:47 AM, jmaher wrote:
>
> Mozilla - 2015 Talos performance regression policy
>
> Over the last year and a half the Talos tests have been rewritten to be
>
6 matches
Mail list logo
