On Friday 2015-03-13 16:06 -0700, Gregory Szorc wrote:
> On Fri, Mar 13, 2015 at 3:49 PM, L. David Baron wrote:
>
> > On Friday 2015-03-13 15:34 -0700, Gregory Szorc wrote:
> > > 1. Create a commit that introduces a new test
> > > 2. Test it
> > > 3. Create a commit that purportedly fixes the tes
On Fri, Mar 13, 2015 at 3:49 PM, L. David Baron wrote:
> On Friday 2015-03-13 15:34 -0700, Gregory Szorc wrote:
> > 1. Create a commit that introduces a new test
> > 2. Test it
> > 3. Create a commit that purportedly fixes the test
> > 4. Build
> > 5. Test and verify
> > 6. Fold the commits
>
> S
On Friday 2015-03-13 15:34 -0700, Gregory Szorc wrote:
> 1. Create a commit that introduces a new test
> 2. Test it
> 3. Create a commit that purportedly fixes the test
> 4. Build
> 5. Test and verify
> 6. Fold the commits
Sure, that's what I'd do in an ideal world. But in reality I
sometimes sta
On Fri, Mar 13, 2015 at 2:25 PM, L. David Baron wrote:
> On Friday 2015-03-13 13:02 -0700, Gregory Szorc wrote:
> > FWIW, I don't think the documentation around the mach commands for test
> > selection is that great. e.g. I'm not sure how many people realize that
> > they can run `mach xpcshell-t
On 12/03/15 16:04, Seth Fowler wrote:
> It looks like it doesn’t anymore, because it works fine in Chrome.
It does; it browser-sniffs.
Gerv
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Sat, Mar 14, 2015 at 1:26 AM, Ted Mielczarek wrote:
> Before we go buying a machine and sticking it under someone's desk
> (although let's not rule that out entirely!) I filed a bug[1] to see if
> we have any existing machines that are virtual machine hosts that have a
> usable CPU such that w
On Friday 2015-03-13 13:02 -0700, Gregory Szorc wrote:
> FWIW, I don't think the documentation around the mach commands for test
> selection is that great. e.g. I'm not sure how many people realize that
> they can run `mach xpcshell-test test_foo.js` from the topsrcdir and all
> `test_foo.js` files
Another pain point: running all relevant tests.
Many features have relevant tests across many test suites, sometimes spread
across different directories. When people are hacking on a feature, they
should have a way to run all relevant tests for that feature. All too often
I've submitted something
On 12/03/15 07:50 PM, Xidorn Quan wrote:
I wonder if it is possible to trigger particular single unittest on which
we observe intermittent failures, instead of the whole test set. I guess it
would save time. I sometimes disable all tests I do not need to check
before pushing to the try to make it
On 12/03/15 07:17 PM, Gijs Kruitbosch wrote:
IME the issue is not so much about not running tests identical to the
ones on CI, but the OS environment which doesn't match, and then
reproducing intermittent failures.
If a failure happens once in 100 builds, it is very annoying for the
sheriffs (ha
> On Mar 13, 2015, at 6:14 AM, Eric Rescorla wrote:
>
> Sorry if this is a dumb question, but it seems like std::pair is fairly
> widely used in our
> code base. Can you explain the circumstances in which you think we should be
> using mozilla::Pair instead?
It’s not at all a dumb question. Th
On Fri, Mar 13, 2015 at 3:39 PM, Mike Conley wrote:
> Perhaps its worth talking to comms to get their input on whether or not
> it's a good time.
>
> But I have to agree with Jared and Mike - I think showing progress,
> especially on the part of performance (perceived or not) can only be a
> good
OrangeFactor suggests that linux is about equal to our other platforms in
terms of catching intermittents:
http://brasstacks.mozilla.com/orangefactor/?display=BugCount&tree=trunk&includefiltertype=quicksearch&includefilterdetailsexcludeResolved=false&includefilterdetailsexcludeDisabled=false&includ
On 3/13/15 7:30 AM, Ted Mielczarek wrote:
Can you file a bug on this specific issue?
Absolutely. https://bugzilla.mozilla.org/show_bug.cgi?id=1143010
(We started running Mochitests in "run by dir" mode which runs a
separate browser per-directory-chunk
Ah, that makes sense. OK, at least no
On Thursday, March 12, 2015 at 6:51:26 PM UTC-4, Jonathan Griffin wrote:
> The quintessential use case here is making it easy to reproduce a try run
> locally, without a local build, using a syntax something like:
>
> * runtests --try 2844bc3a9227
>
> Ideally, this would download the appropriate
Perhaps its worth talking to comms to get their input on whether or not
it's a good time.
But I have to agree with Jared and Mike - I think showing progress,
especially on the part of performance (perceived or not) can only be a
good thing.
-Mike
On 13/03/2015 5:17 AM, Mike de Boer wrote:
> Yeah
On 03/13/2015 12:26 PM, Ted Mielczarek wrote:
The other question I have is: what percentage of our intermittent
failures occur on Linux? If it's not that high then this is a lot of
investment for minimal gain.
FYI, there have been several intermittent crashes reported on Linux test
runs lately,
tracker bug with details: https://bugzil.la/1141402
status at: https://treestatus.mozilla.org/
IT and Release Operations will be performing maintenance work this
Saturday. The work is expected to be invasive, and we will close the
trees for the duration of the window, 8 hours from 0600 PDT to 1
On Thu, Mar 12, 2015 at 4:43 PM, Ehsan Akhgari
wrote:
> On 2015-03-12 6:54 PM, Kyle Huey wrote:
>
>> I've been meaning to rip out the putative support for this from XHR (and
>> all of the complexity that it introduces) for months now. This would be
>> great.
>>
>
> Henri beat you by two years.
Sorry if this is a dumb question, but it seems like std::pair is fairly
widely used in our
code base. Can you explain the circumstances in which you think we should be
using mozilla::Pair instead?
Ekr
On Thu, Mar 12, 2015 at 5:53 PM, Seth Fowler wrote:
> I thought I’d let everyone know that bu
On 12/03/15 22:51, Jonathan Griffin wrote:
> The A-Team is embarking on a project to improve the developer experience
> when running unittests locally. This project will address the following
> frequently-heard complaints:
>
> * Locally developers often use mach to run tests, but tests in CI use
On Thu, Mar 12, 2015, at 08:50 PM, Robert O'Callahan wrote:
> On Fri, Mar 13, 2015 at 12:34 PM, Seth Fowler wrote:
> To work around these issues, I would like to have a dedicated machine
> that
> continuously downloads builds and runs tests under rr. Ideally it would
> reenable tests that have be
On Thu, Mar 12, 2015, at 07:48 PM, Boris Zbarsky wrote:
> On 3/12/15 6:51 PM, Jonathan Griffin wrote:
> > What other use cases would you like us to address, which aren't derivatives
> > of the above issues?
>
> I ran into a problem just yesterday: I wanted to run mochitest-browser
> locally, to d
Yeah, Jared makes a good point - exactly the reason why I reacted so
enthusiastically to this announcement is that I’d never heard of Project Silk,
even though I read HN (headlines, not comments ;-) ) on a daily basis. Or maybe
it did, but perhaps it being all about B2G and sort of like ‘Android
24 matches
Mail list logo
