On 17:26, Tue, 23 Sep, Kyle Huey wrote:
On Tue, Aug 26, 2014 at 8:23 AM, Chris AtLee wrote:
Just a short note to say that this experiment is now live on
mozilla-inbound.
___
dev-tree-management mailing list
dev-tree-managem...@lists.mozilla.org
https
On Tue, Aug 26, 2014 at 8:23 AM, Chris AtLee wrote:
> Just a short note to say that this experiment is now live on
> mozilla-inbound.
>
> ___
> dev-tree-management mailing list
> dev-tree-managem...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/
Just a short note to say that this experiment is now live on
mozilla-inbound.
signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Thu, Aug 21, 2014 at 3:21 PM, Jonathan Griffin wrote:
> In summary, the sheriffs won't be backing out extra commits because of the
> coalescing, and it remains the sheriffs' job to backfill tests when they
> determine they need to do so in order to bisect a failure. We aren't
> placing any ex
On Thu, Aug 21, 2014 at 03:03:30PM -0700, Jonas Sicking wrote:
> What will be the policy if a test fails and it's unclear which push
> caused the regression?
You may have missed the main point that it's not "What will", but "What
is". It *is* already the case that tests are skipped.
Mike
It will be handled just like coalesced jobs today: sheriffs will
backfill the missing data, and backout only the offender.
An illustration might help. Today we might have something like this,
for a given job:
linux64-debug win7-debug osx8-debug
commit 1 pass pass
What will be the policy if a test fails and it's unclear which push
caused the regression? Is it the sheriff's job, or the people who
pushed's job to figure out which push was the culprit and make sure
that that push gets backed out?
I.e. if 4 pushes land between two testruns, and we see a regress
Hey Martin,
This is a good idea, and we've been thinking about approaches like
this. Basically, the idea is to run tests that "(nearly) always pass"
less often. There are currently some tests that fit into this category,
like dom level0,1,2 tests in mochitest-plain, and those are
time-consu
Thanks Ed. To paraphrase, no test coverage is being lost here, we're
just being a little more deliberate with job coalescing. All tests will
be run on all platforms (including debug tests) on a commit before a
merge to m-c.
Jonathan
On 8/21/2014 9:35 AM, Ed Morley wrote:
I think much of the
On 8/21/14 9:35 AM, Ed Morley wrote:
4) When merging into mozilla-central, sheriffs ensure that all jobs are
green - including those that got coalesced and those that are only
scheduled periodically (eg non-unified & PGO builds are only run every 3
hours). (This is a fairly manual process current
On 20/08/14 17:37, Jonas Sicking wrote:
It would however be really cool if we were able to pull data on which
tests tend to fail in a way that affects all platforms, and which ones
tend to fail on one platform only.
Here's a potential project that might help. For all of the trees
(probably tr
I think much of the pushback in this thread is due to a misunderstanding
of some combination of:
* our current buildbot scheduling
* the proposal
* how trees are sheriffed and merged
To clarify:
1) We already have coalescing [*] of jobs on all trees apart from try.
2) This coalescing means tha
--
- Milan
On Aug 21, 2014, at 10:12 , Chris AtLee wrote:
> On 17:37, Wed, 20 Aug, Jonas Sicking wrote:
>> On Wed, Aug 20, 2014 at 4:24 PM, Jeff Gilbert wrote:
>>> I have been asked in the past if we really need to run WebGL tests on
>>> Android, if they have coverage on Desktop platforms.
>>
On 17:37, Wed, 20 Aug, Jonas Sicking wrote:
On Wed, Aug 20, 2014 at 4:24 PM, Jeff Gilbert wrote:
I have been asked in the past if we really need to run WebGL tests on Android,
if they have coverage on Desktop platforms.
And then again later, why B2G if we have Android.
There seems to be enoug
On Wed, Aug 20, 2014 at 4:24 PM, Jeff Gilbert wrote:
> I have been asked in the past if we really need to run WebGL tests on
> Android, if they have coverage on Desktop platforms.
> And then again later, why B2G if we have Android.
>
> There seems to be enough belief in test-once-run-everywhere t
> From: "Ehsan Akhgari"
> To: "Jeff Gilbert"
> Cc: "Chris AtLee" , "Jonathan Griffin"
> , dev-platform@lists.mozilla.org
> Sent: Wednesday, August 20, 2014 4:00:15 PM
> Subject: Re: Experiment with running debug tests less often on
>
On 2014-08-20, 6:29 PM, Jeff Gilbert wrote:
If running debug tests on a single platform is generally sufficient for
non-graphics bugs,
It is not. That is the point I was trying to make. :-)
> it might be useful to have the Graphics branch run debug tests on all
platforms, for use with grap
Chris AtLee"
Cc: "Jonathan Griffin" , dev-platform@lists.mozilla.org
Sent: Wednesday, August 20, 2014 3:16:31 PM
Subject: Re: Experiment with running debug tests less often on mozilla-inbound
the week of August 25
On 2014-08-20, 5:46 PM, Jeff Gilbert wrote:
> Graphics in pa
On 2014-08-20, 5:46 PM, Jeff Gilbert wrote:
Graphics in particular is plagued by non-cross-platform code. Debug coverage on
Linux gives us no practical coverage for our windows, mac, android, or b2g
code. Maybe this is better solved with reviving the Graphics branch, however.
Having more bran
"
To: "Ehsan Akhgari"
Cc: "Jonathan Griffin" , "Jeff Gilbert"
, dev-platform@lists.mozilla.org
Sent: Wednesday, August 20, 2014 9:02:14 AM
Subject: Re: Experiment with running debug tests less often on mozilla-inbound
the week of August 25
On 18:25, Tue, 19 Aug
On Wed, Aug 20, 2014 at 03:58:55PM +0100, Ed Morley wrote:
> On 19/08/2014 21:55, Benoit Girard wrote:
> >I completely agree with Jeff Gilbert on this one.
> >
> >I think we should try to coalesce -better-. I just checked the current
> >state of mozilla-inbound and it doesn't feel any of the curren
On 2014-08-20, 12:02 PM, Chris AtLee wrote:
On 18:25, Tue, 19 Aug, Ehsan Akhgari wrote:
On 2014-08-19, 5:49 PM, Jonathan Griffin wrote:
On 8/19/2014 2:41 PM, Ehsan Akhgari wrote:
On 2014-08-19, 3:57 PM, Jeff Gilbert wrote:
I would actually say that debug tests are more important for
continuou
On 18:25, Tue, 19 Aug, Ehsan Akhgari wrote:
On 2014-08-19, 5:49 PM, Jonathan Griffin wrote:
On 8/19/2014 2:41 PM, Ehsan Akhgari wrote:
On 2014-08-19, 3:57 PM, Jeff Gilbert wrote:
I would actually say that debug tests are more important for
continuous integration than opt tests. At least in cod
On 14-08-20 11:48 AM, Ehsan Akhgari wrote:
> On 2014-08-20, 10:58 AM, Ed Morley wrote:
>> On 19/08/2014 21:55, Benoit Girard wrote:
>>> I completely agree with Jeff Gilbert on this one.
>>>
>>> I think we should try to coalesce -better-. I just checked the current
>>> state of mozilla-inbound and i
On 2014-08-20, 10:58 AM, Ed Morley wrote:
On 19/08/2014 21:55, Benoit Girard wrote:
I completely agree with Jeff Gilbert on this one.
I think we should try to coalesce -better-. I just checked the current
state of mozilla-inbound and it doesn't feel any of the current patch
really need their ow
On 19/08/2014 21:55, Benoit Girard wrote:
I completely agree with Jeff Gilbert on this one.
I think we should try to coalesce -better-. I just checked the current
state of mozilla-inbound and it doesn't feel any of the current patch
really need their own set of tests because they're are not time
On 8/20/2014 3:07 AM, Mike Hommey wrote:
Optimized builds have been the default for a while, if not ever[1].
Bug 54828 made optimized builds the default in 2004 right before we
released Firefox 1.0. It only took four years to make that decision ;-)
--BDS
___
On Tue, Aug 19, 2014 at 11:26:42PM -0700, Jeff Gilbert wrote:
> I was just going to ask about this. I glanced through the mozconfigs
> in the tree for at least Linux debug, but it looks like it only has
> --enable-debug, not even -O1. Maybe it's buried somewhere in there,
> but I didn't find it wit
only care about pass/fail, and not crash stacks/debugability)
-Jeff
- Original Message -
From: "Kyle Huey"
To: "Joshua Cranmer 🐧"
Cc: "dev-platform"
Sent: Tuesday, August 19, 2014 3:56:27 PM
Subject: Re: Experiment with running debug tests less often on
I'm pretty sure the debug builds on our CI infrastructure are built
with optimization.
- Kyle
On Tue, Aug 19, 2014 at 3:42 PM, Joshua Cranmer 🐧 wrote:
> On 8/19/2014 5:25 PM, Ehsan Akhgari wrote:
>>
>> Yep, the debug tests indeed take more time, mostly because they run more
>> checks.
>
>
> Actu
On 8/19/2014 5:25 PM, Ehsan Akhgari wrote:
Yep, the debug tests indeed take more time, mostly because they run
more checks.
Actually, the bigger cause in the slowdown is probably that debug tests
don't have any optimizations, not more checks. An atomic increment on a
debug build invokes somet
No, fx-team is not affected by this experiment; we intend to target
mozilla-inbound only for this 1-week trial. The reason is that the
number of commits on m-i seems larger than fx-team, and therefore the
impacts should be more visible.
Jonathan
On 8/19/2014 3:19 PM, Matthew N. wrote:
On 8/
On Tue, Aug 19, 2014 at 02:49:48PM -0700, Jonathan Griffin wrote:
> On 8/19/2014 2:41 PM, Ehsan Akhgari wrote:
> >On 2014-08-19, 3:57 PM, Jeff Gilbert wrote:
> >>I would actually say that debug tests are more important for continuous
> >>integration than opt tests. At least in code I deal with, we
I know this is tangential but the small changes are the least tested
changes in my experience. The try push requirement for checkin-needed
has had a wonderful impact on the amount of times the tree is closed[1].
The tree is less likely to be closed these days.
David
[1] http://futurama.theaut
On 2014-08-19, 5:49 PM, Jonathan Griffin wrote:
On 8/19/2014 2:41 PM, Ehsan Akhgari wrote:
On 2014-08-19, 3:57 PM, Jeff Gilbert wrote:
I would actually say that debug tests are more important for
continuous integration than opt tests. At least in code I deal with,
we have a ton of asserts to gu
On 8/19/14 12:22 PM, Jonathan Griffin wrote:
To assess the impact of doing this, we will be performing an experiment
the week of August 25, in which we will run debug tests on
mozilla-inbound on most desktop platforms every other run, instead of
every run as we do now. Debug tests on linux64 wil
On 8/19/2014 2:41 PM, Ehsan Akhgari wrote:
On 2014-08-19, 3:57 PM, Jeff Gilbert wrote:
I would actually say that debug tests are more important for
continuous integration than opt tests. At least in code I deal with,
we have a ton of asserts to guarantee behavior, and we really want
test cover
s less often is on the same scale of bad, but
I would like to express my concerns about heading in that direction.
-Jeff
- Original Message -
From: "Jonathan Griffin"
To: dev-platform@lists.mozilla.org
Sent: Tuesday, August 19, 2014 12:22:21 PM
Subject: Experiment with running
On 2014-08-19, 3:57 PM, Jeff Gilbert wrote:
I would actually say that debug tests are more important for continuous
integration than opt tests. At least in code I deal with, we have a ton of
asserts to guarantee behavior, and we really want test coverage with these via
CI. If a test passes on
On 2014-08-19 1:55 PM, Benoit Girard wrote:
> Perhaps we should instead promote checkin-needed (or a similar simple)
> to coalesce simple changes together.
I would prefer to use 'checkin-needed' for more things, but am blocked
by the try-needed requirement. We need some way to bless small changes
t; -Jeff
>
> - Original Message -
> From: "Jonathan Griffin"
> To: dev-platform@lists.mozilla.org
> Sent: Tuesday, August 19, 2014 12:22:21 PM
> Subject: Experiment with running debug tests less often on mozilla-inbound
> the week of August 25
>
> Our pools of
onathan Griffin"
To: dev-platform@lists.mozilla.org
Sent: Tuesday, August 19, 2014 12:22:21 PM
Subject: Experiment with running debug tests less often on mozilla-inbound
the week of August 25
Our pools of test slaves are often at or over capacity, and this has the
effect of increasin
Our pools of test slaves are often at or over capacity, and this has the
effect of increasing job coalescing and test wait times. This, in turn,
can lead to longer tree closures caused by test bustage, and can cause
try runs to be very slow to complete.
One of the easiest ways to mitigate thi
43 matches
Mail list logo
