I think tracking and investigating is all of our responsibility. QA definitely
has a role to play and I think we've been playing that role to a certain
extent. We don't always have the skills, knowledge, experience, or time to help
but we always try and we are always willing to learn. We rely on
On 31/08/12 13:13, Dave Mandelin wrote:
Otherwise, it seems we just have to share the pain. Bisecting changesets is not
necessarily an enjoyable job but it is a necessary one. I would suggest that
sheriffs pick one of the 5 committers and ask that person to bisect the change
and try not to pic
On Thursday, August 30, 2012 2:54:55 PM UTC-7, Ehsan Akhgari wrote:
> Oh, sorry, I needed to ask my question better. I'm specifically
> wondering who needs to track and investigate the regression if it
> happened on a range of, let's say, 5 committers...
Ah. I believe that's a job for a bugmast
On 08/30/12 07:22 PM, L. David Baron wrote:
> On Thursday 2012-08-30 14:42 -0700, Taras Glek wrote:
>> * Joel will revisit maintaining Talos within mozilla-central to
>> reduce developer barriers to understanding what a particular Talos
>> test result means. This should also make Talos easier to ru
Some people have noted in the past that some Talos measurements are not
representative of something that the users would see, the Talos numbers
are noisy, and we don't have good tools to deal with these types of
regressions. There might be some truth to all of these, but I believe
that the bigger
On Thursday 2012-08-30 14:42 -0700, Taras Glek wrote:
> * Joel will revisit maintaining Talos within mozilla-central to
> reduce developer barriers to understanding what a particular Talos
> test result means. This should also make Talos easier to run
This will also solve one of the other problems
On 12-08-30 5:42 PM, Taras Glek wrote:
* Joel will revisit maintaining Talos within mozilla-central to reduce
developer barriers to understanding what a particular Talos test result
means. This should also make Talos easier to run
I have filed bug 787200 for this discussion.
Ehsan
On 12-08-30 5:28 PM, Dave Mandelin wrote:
On Thursday, August 30, 2012 9:11:25 AM UTC-7, Ehsan Akhgari wrote:
On 12-08-29 9:20 PM, Dave Mandelin wrote:
On Wednesday, August 29, 2012 4:03:24 PM UTC-7, Ehsan Akhgari wrote:
In my opinion, one of the reasons why Talos is disliked is because many
Hi,
We had a quick meeting focused on how to not regress Talos.
Attendance: Taras Glek, Ehsan Akhgari, Clint Talbert, Nathan Froyd, Dave
Mandelin, Christina Choi, Joel Maher
Notes:
* Clint's Automation&Tools team is improving Talos reporting abilities.
We should have much better tools for c
On Thursday, August 30, 2012 9:11:25 AM UTC-7, Ehsan Akhgari wrote:
> On 12-08-29 9:20 PM, Dave Mandelin wrote:
>
> > On Wednesday, August 29, 2012 4:03:24 PM UTC-7, Ehsan Akhgari wrote:
>
> In my opinion, one of the reasons why Talos is disliked is because many
> people don't know where its cod
On 12-08-29 9:46 PM, Joshua Cranmer wrote:
On 8/29/2012 6:03 PM, Ehsan Akhgari wrote:
Hi everyone,
The Talos regression detection emails caught a number of regressions
during the Monday uplift (see [1] for Aurora and [2] for Beta
regressions). To put things into perspective, I prepared a
sprea
On 12-08-29 9:20 PM, Dave Mandelin wrote:
On Wednesday, August 29, 2012 4:03:24 PM UTC-7, Ehsan Akhgari wrote:
Hi everyone,
The way the current situation happens is that many of the developers
ignore the Talos regression emails that go to dev-tree-management,
Talos is widely disliked and dist
On 12-08-30 2:34 AM, Mike Hommey wrote:
On Wed, Aug 29, 2012 at 07:03:17PM -0400, Ehsan Akhgari wrote:
I don't believe that the current situation is acceptable, especially
with the recent focus on performance (through the Snappy project),
and I would like to ask people if they have any ideas on
You'll need to be more specific about how this code is "not working" to
receive any useful replies, I suspect. Also, that ss prefix on the third
line might be causing havoc.
Cheers,
Josh
On 08/30/2012 12:37 AM, Malintha Adikari wrote:
var oFile = DirIO.get("ProfD"); // %Profile% dir
oFile.app
On Thu, Aug 30, 2012 at 10:06 AM, Boris Zbarsky wrote:
> On 8/30/12 8:26 AM, Jonas Sicking wrote:
>>
>> What would
>>
>>readonly attribute long? bin;
>>
>> compile into? If it compiles into something called GetBin then we'd
>> have a nice consistency that any getters for nullable types are nam
On 8/30/12 8:26 AM, Jonas Sicking wrote:
What would
readonly attribute long? bin;
compile into? If it compiles into something called GetBin then we'd
have a nice consistency that any getters for nullable types are named
GetX and any getters for non-nullable types are named X.
I was going t
On 8/30/12 4:16 AM, Ms2ger wrote:
It certainly looks nicer, but I'm not a big fan of complicating the
rules for assembling the C++ signature from the WebIDL. XPIDL's
consistency here, IMO, saves time when implementing an interface: you
can focus on the actual implementation, rather than the bindi
On 08/29/2012 07:32 PM, Nicholas Nethercote wrote:
> In my experience, a lot of those emails say "there was a regression
> caused by one of the following 100 patches", and I will have written 1
> of those patches. I usually ignore those ones (though it depends on
> the nature of the patch).
>
>
On 08/29/2012 09:54 PM, Robert O'Callahan wrote:
> On Thu, Aug 30, 2012 at 1:00 PM, Ehsan Akhgari wrote:
>
>> I agree with that if we talk about performance in general. But this
>> thread is about specific regressions in performance as a result of
>> changeset going into our tree. I don't think
On Wed, Aug 29, 2012 at 5:20 PM, Boris Zbarsky wrote:
> Right now, attribute getters always get prefixed with "Get" in the WebIDL
> bindings. So "readonly attribute long foo" becomes "int32_t GetFoo()" in
> the C++.
>
> Would it make sense to drop the Get in certain cases? In particular, in
> ca
I've just filed bug 786978 for this.
- Matt
- Original Message -
From: "Ehsan Akhgari"
To: rob...@ocallahan.org
Cc: dev-platform@lists.mozilla.org
Sent: Thursday, August 30, 2012 1:02:43 PM
Subject: Re: The current state of Talos benchmarks
On 12-08-29 8:41 PM, Robert O'Callahan wrote:
On Thu, Aug 30, 2012 at 3:34 AM, Mike Hommey wrote:
> Ideally, we should make talos regressions visible on tbpl as oranges,
> and star them as other oranges.
FWIW, making this possible is an explicit goal of the SfN effort.
-Justin
___
dev-platform mai
On 08/29/2012 10:20 PM, Boris Zbarsky wrote:
Right now, attribute getters always get prefixed with "Get" in the
WebIDL bindings. So "readonly attribute long foo" becomes "int32_t
GetFoo()" in the C++.
Would it make sense to drop the Get in certain cases? In particular, in
cases in which:
1)
23 matches
Mail list logo
