On 17:26, Tue, 23 Sep, Kyle Huey wrote:
On Tue, Aug 26, 2014 at 8:23 AM, Chris AtLee cat...@mozilla.com wrote:
Just a short note to say that this experiment is now live on
mozilla-inbound.
___
dev-tree-management mailing list
On Tue, Aug 26, 2014 at 8:23 AM, Chris AtLee cat...@mozilla.com 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
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 17:37, Wed, 20 Aug, Jonas Sicking wrote:
On Wed, Aug 20, 2014 at 4:24 PM, Jeff Gilbert jgilb...@mozilla.com 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.
--
- Milan
On Aug 21, 2014, at 10:12 , Chris AtLee cat...@mozilla.com wrote:
On 17:37, Wed, 20 Aug, Jonas Sicking wrote:
On Wed, Aug 20, 2014 at 4:24 PM, Jeff Gilbert jgilb...@mozilla.com wrote:
I have been asked in the past if we really need to run WebGL tests on
Android, if they have
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
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
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
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
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
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
On Thu, Aug 21, 2014 at 3:21 PM, Jonathan Griffin jgrif...@mozilla.com 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
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 with a
quick look.
I took a look at the build log for WinXP debug,
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 with a
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 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
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
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
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 current patch
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.
-Jeff
- Original Message -
From: Chris AtLee
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
If running debug tests on a single platform is generally sufficient for
non-graphics bugs, it might be useful to have the Graphics branch run debug
tests on all platforms, for use with graphics checkins. (while running a
decreased number of debug tests on the main branches) It's still possible
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
From: Ehsan Akhgari ehsan.akhg...@gmail.com
To: Jeff Gilbert jgilb...@mozilla.com
Cc: Chris AtLee cat...@mozilla.com, Jonathan Griffin
jgrif...@mozilla.com, dev-platform@lists.mozilla.org
Sent: Wednesday, August 20, 2014 4:00:15 PM
Subject: Re: Experiment with running debug tests less often
On Wed, Aug 20, 2014 at 4:24 PM, Jeff Gilbert jgilb...@mozilla.com 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
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 debug, it should almost certainly pass on
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
sensitive or sufficiently complex. Right
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
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
I also agree about coalescing better. We are looking at ways to do that
in conjunction with
https://wiki.mozilla.org/Auto-tools/Projects/Autoland, which we'll have
a prototype of by the end of the quarter. In this model, commits that
are going through autoland could be coalesced when landing
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
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
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
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]
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 have a
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
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
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 pidgeo...@gmail.com wrote:
On 8/19/2014 5:25 PM, Ehsan Akhgari wrote:
Yep, the debug tests indeed take more time, mostly because they run more
39 matches
Mail list logo
