Re: Replacing Mozmill driven tests for Firefox with Marionette
On 13 May 2015, at 04:40, Philip Chee philip.c...@gmail.com wrote: On 12/05/2015 20:23, Henrik Skupin wrote: To being able to better spread work around we basically have chosen the wider known Marionette framework. Thunderbird currently uses mozmill. Will Marionette[1] be available for Thunderbird? Is there a porting guide? I can’t think of any obvious reasons why Marionette couldn’t be made to work against Thunderbird’s chrome when it works against Firefox’. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing Mozmill driven tests for Firefox with Marionette
I don't believe marionette currently works on Thunderbird, but that's most likely due to hardcoded assumptions than any deep technical reasons. It could probably be made to work with a little bit of effort, it's just that to date, no one has tried. I thought thunderbird was using a very out-of-date version of mozmill which was already unmaintained anyway? Or did you already upgrade to the latest version? -Andrew On 12/05/15 11:40 PM, Philip Chee wrote: On 12/05/2015 20:23, Henrik Skupin wrote: Hi all, I would like to finally announce that we are going to discontinue any kind of development for the Mozmill framework and tests for Firefox. The reason is that there is simply no man power to further develop this tool. Also it's plainly only myself who has the knowledge of how it works and how it grew over the past 6 years. It's simply not scalable anymore. Since end of last year we (members of the A-Team) were actively working on replacing our tests. As you can imagine there is lots of work to do. To being able to better spread work around we basically have chosen the wider known Marionette framework. It's already in use by some products, has the standardized Webdriver API, and has a better platform for today's requirements compared to Mozmill. So lots of new features and bug fixes went into Marionette during the last quarter. All of those were necessary to support at least the most important features of Mozmill like running different locales, exercising restart tests, and others. As result we now have Marionette in a state to get started in replacing Mozmill tests. We even have some tests converted last quarter, so the important security and update tests could be flipped over to Marionette now. The new test suite itself is named Firefox UI Tests and can be accessed via: https://github.com/mozilla/firefox-ui-tests. Thunderbird currently uses mozmill. Will Marionette[1] be available for Thunderbird? Is there a porting guide? Phil ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
I think it's time I made an official decision here. I think Ehsan's proposal makes a lot of sense both as good engineering and because we know Google has already proved it for us. I approve. Ehsan, will you please make the necessary changes to our style guide? --BDS On Mon, Apr 27, 2015 at 3:48 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Right now, our coding style requires that both the virtual and override keywords to be specified for overridden virtual functions. A few things have changed since we decided that a number of years ago: 1. The override and final keywords are now available on all of the compilers that we build with, and we have stopped supporting compilers that do not support these features. 2. We have very recently gained the ability to run clang-based mass source code transformations over our code that would let us enforce the coding style [1]. I would like to propose a change to our coding style, and run a mass transformation over our code in order to enforce it. I think we should change it to require the usage of exactly one of these keywords per *overridden* function: virtual, override, and final. Here are the advantages: * It is a more succinct, as |virtual void foo() override;| doesn't convey more information than |void foo() override;|. * It can be easily enforced using clang-tidy across the entire code base. * It makes it easier to determine what kind of function you are looking at by just looking at its declaration. |virtual void foo();| means a virtual function that is not overridden, |void foo() override;| means an overridden virtual function, and |void foo() final;| means an overridden virtual function that cannot be further overridden. * It allows us to be in sync with the Google C++ Style on this issue [2]. * It will allow us to remove NS_IMETHODIMP, and use NS_IMETHOD instead. Please let me know what you think! [1] Facilitated by bug 904572. Also see bug 1158776 for my first attempt at this. [2] http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Inheritance Cheers, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Benjamin Smedberg Engineering Manager, Firefox ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to remove: mochitest-flavor mach commands
Does this include subsuites like devtools? There is currently a bug on file in which `mach mochitest` doesn’t work with devtools tests (1122590). Until that is resolved, if mochitest-devtools was removed then running these tests would become the harder-to-remember `./mach mochitest browser/devtools --subsuite devtools` as opposed to `./mach mochitest-devtools browser/devtools`. I'd request that mochitest-devtools remains in place until it's possible to run simply `mach mochitest browser/devtools` Thanks, Brian On May 13, 2015, at 12:54 PM, Andrew Halberstadt ahalberst...@mozilla.com wrote: As mentioned previously in another post, work is under way to remove the flavor specific mochitest commands (e.g mach mochitest-plain, mach mochitest-browser etc.). This is being tracked in bug 1164597 [1]. Bug description pasted below: As part of an effort to make running tests as easy and intuitive as possible, I'd like to consolidate all of the mochitest-flavor mach commands into the single |mach mochitest| command. Currently |mach mochitest| will automatically detect the flavor of mochitests you wish to run. If you specify a directory that contains multiple flavors, each flavor will be run in sequence. For example: ./mach mochitest dom/indexedDB runs all the mochitest-chrome, mochitest-browser-chrome and mochitest-plain tests in that directory. The flavor can be limited by passing in -f (--flavor). So to only run the chrome tests in that directory you'd use: ./mach mochitest -f chrome dom/indexedDB Commands of the form |mach mochitest-flavor| will be removed: ./mach mochitest-plain - ./mach mochitest -f plain ./mach mochitest-browser - ./mach mochitest -f browser etc.. I believe this will make running tests easier and more intuitive. The fact that different flavors of mochitest exist will become a background implementation detail. Instead, an emphasis will be placed on running directories of tests, or tests related to certain features. The knowledge of which test belongs to which flavor will no longer be required, but of course the ability to run specific flavors will still be there for those who need it. The described behaviour for |mach mochitest| above, already exists today. This bug is about making it the defacto way to run mochitests (maybe aside from |mach test|). This bug will also add b2g and android support to |mach mochitest|. Exceptions to this will be robocop, webapprt-chrome and webapprt-content which for technical reasons will not be rolled into |mach mochitest| (for now). Please let me know if you have any questions or concerns, -Andrew [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1164597 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to remove: mochitest-flavor mach commands
On 13/05/15 04:13 PM, Brian Grinstead wrote: Does this include subsuites like devtools? There is currently a bug on file in which `mach mochitest` doesn’t work with devtools tests (1122590). Until that is resolved, if mochitest-devtools was removed then running these tests would become the harder-to-remember `./mach mochitest browser/devtools --subsuite devtools` as opposed to `./mach mochitest-devtools browser/devtools`. I'd request that mochitest-devtools remains in place until it's possible to run simply `mach mochitest browser/devtools` Thanks, Brian Yes it does. I actually already have ./mach mochitest browser/devtools working in my local patch (posted in bug 1164597). We'll be able to resolve bug 1122590 automatically once it lands. Cheers, Andrew p.s ./mach mochitest browser/devtools --subsuite devtools works currently. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: The mochitest ise() function is dead, please use is() instead
ise() was an alias to is() as of bug 949614. I landed bug 1154275 on inbound today which removes ise() and replaces its usages with is(). Since is() now does a === comparison by default, there should be no reason to use ise(). Cheers, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: PR_LOGGING is dead, please stop using it
Way back yonder in September we enabled logging by default on all builds. The
world did not end. The |--disable-logging| flag remained which in theory, does
in fact disable logging but none of our default builds use it, and
unsurprisingly we occasionally started breaking custom builds that attempted to
use it.
In bug 1161238 [1] we plan to remove |--disable-logging| completely, as part of
that effort we have removed (or are about to) every instance of |#ifdef
PR_LOGGING| from gecko code. So no more chance of breaking builds. But also now
it's pretty clear if you are doing things you shouldn't. I found plenty of
examples where it was assumed PR_LOGGING being defined was a rare thing (which,
fair enough, it used to be). I've cleaned up most of the ones I found, but if
you're responsible for code that is using logging I suggest you did a quick
audit once I land bug 1161238.
They often took the form of something like this:
#ifdef PR_LOGGING
nsCString message = do_a_couple_of_queries_and_build_a_msg();
PR_LOG(foo, PR_LOG_DEBUG, (message = %s, message.get()));
#endif
This seems innocuous enough, it's protected by an ifdef! Unfortunately that
ifdef is generally always true now. Fear not, there's a better way!
Wrap that sucker in a |PR_LOG_TEST|:
if (PR_LOG_TEST(foo, PR_LOG_DEBUG)) {
nsCString message = do_a_couple_of_queries_and_build_a_msg();
PR_LOG(foo, PR_LOG_DEBUG, (message = %s, message.get()));
}
Still sketched out? Is it debug only worthy? Well lets up that to a |#ifdef
MOZ_DEBUG|:
#ifdef MOZ_DEBUG
if (PR_LOG_TEST(foo, PR_LOG_DEBUG)) {
nsCString message = do_a_couple_of_queries_and_build_a_msg();
PR_LOG(foo, PR_LOG_DEBUG, (message = %s, message.get()));
}
#endif
Note, something like the following is fine, it only gets evaluated if the log
level is PR_LOG_DEBUG:
PR_LOG(foo, PR_LOG_DEBUG, (message = %s,
do_a_couple_of_queries_and_build_a_msg().get()));
In the coming months I hope to land further logging enhancements, stay tuned!
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1161238
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: The mochitest ise() function is dead, please use is() instead
On Wed, May 13, 2015 at 3:52 PM, Martin Thomson m...@mozilla.com wrote: On Wed, May 13, 2015 at 3:46 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: ise() was an alias to is() as of bug 949614. I landed bug 1154275 on inbound today which removes ise() and replaces its usages with is(). Since is() now does a === comparison by default, there should be no reason to use ise(). \o/ Incidentally, are we prepared to have a discussion about the relative merits of == and ===? I see a lot of code that is open to type coercion bugs and I've been told that == is in the official style (though I note its absence from https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#JavaScript_practices just now). Apologies if I hijack your thread. I do want to continue to strongly encourage wider use of code deletion as a means of making progress. I consider use of == in JavaScript testing code to be a bug: the == operator is just too wonky. I would steer people in the direction of Assert.jsm, specifically Assert.deepEqual, which uses ObjectUtils.jsm goodness for type aware comparisons so things like Date, RegExp, and Object comparisons have sane behavior. (deepEqual falls back to === for non-special types. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to remove: mochitest-flavor mach commands
On Wed, May 13, 2015 at 2:03 PM, Ms2ger ms2...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/13/2015 09:54 PM, Andrew Halberstadt wrote: As mentioned previously in another post, work is under way to remove the flavor specific mochitest commands (e.g mach mochitest-plain, mach mochitest-browser etc.). Does this include `mochitest-1` and friends? These are a lot easier to use than having to figure out the exact incantation for the chunked suites. IIRC `mochitest-1` and other job-name based arguments are only exposed/supported via `mach test`. I don't believe Andrew's work will impact these. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: The mochitest ise() function is dead, please use is() instead
On Wed, May 13, 2015 at 3:46 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: ise() was an alias to is() as of bug 949614. I landed bug 1154275 on inbound today which removes ise() and replaces its usages with is(). Since is() now does a === comparison by default, there should be no reason to use ise(). \o/ Incidentally, are we prepared to have a discussion about the relative merits of == and ===? I see a lot of code that is open to type coercion bugs and I've been told that == is in the official style (though I note its absence from https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#JavaScript_practices just now). Apologies if I hijack your thread. I do want to continue to strongly encourage wider use of code deletion as a means of making progress. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: The mochitest ise() function is dead, please use is() instead
On Wed, May 13, 2015 at 4:54 PM, Matthew N. mattn+firefox-...@mozilla.com wrote: In JavaScript, == is preferred to ===. from https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Operators Ahh, that's where it was hiding. Can we reverse that statement please? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing Mozmill driven tests for Firefox with Marionette
Ouch, there was a line near the end. Successfully installed jsbridge-2.4.14 mozmill-1.5.16 This is from a local C-C TB build. CI ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: The mochitest ise() function is dead, please use is() instead
On 5/13/15 7:35 PM, Gregory Szorc wrote: I would steer people in the direction of Assert.jsm, specifically Assert.deepEqual This should be used very very carefully. As a very simple example, using this (or worse yet notDeepEqual) in any test that tries to check for equality of Window objects is not a good idea. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
If you run mozharness on your local machine (tooltool changes)
Hello all, At the end of last year we made some changes to make mozharness more easy to run outside of the Release Engineering VPN. Mozharness is the python harness that runs most jobs that show up on Treeherder. Tooltool has been re-written recently [1], you will now need a token on your machine (documented) [2]. Tooltool allows fetching binaries (public and private) into a machine, it does verifications and caching if needed. In general, if you try to run mozharness as a developer to troubleshoot an issue and you start having trouble, file a bug (see docs' header) with the details and if we can't help you on #ateam/#releng look into requesting a loaner so you are not blocked (added note in docs). Some jobs can be very dependent to the machines they're running on the CI and can not easily be run outside of the intended setup. Where possible we would like to fix this. regards, Armen [1] http://code.v.igoro.us/posts/2015/04/new-tooltool-in-production.html [2] https://wiki.mozilla.org/ReleaseEngineering/Mozharness/How_to_run_tests_as_a_developer#Step_2_-_Create_a_tooltool_token_.28fetches_artifacts_for_you.29 -- Zambrano Gasparnian, Armen Automation Tools Engineer http://armenzg.blogspot.ca ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to remove: mochitest-flavor mach commands
As mentioned previously in another post, work is under way to remove the flavor specific mochitest commands (e.g mach mochitest-plain, mach mochitest-browser etc.). This is being tracked in bug 1164597 [1]. Bug description pasted below: As part of an effort to make running tests as easy and intuitive as possible, I'd like to consolidate all of the mochitest-flavor mach commands into the single |mach mochitest| command. Currently |mach mochitest| will automatically detect the flavor of mochitests you wish to run. If you specify a directory that contains multiple flavors, each flavor will be run in sequence. For example: ./mach mochitest dom/indexedDB runs all the mochitest-chrome, mochitest-browser-chrome and mochitest-plain tests in that directory. The flavor can be limited by passing in -f (--flavor). So to only run the chrome tests in that directory you'd use: ./mach mochitest -f chrome dom/indexedDB Commands of the form |mach mochitest-flavor| will be removed: ./mach mochitest-plain - ./mach mochitest -f plain ./mach mochitest-browser - ./mach mochitest -f browser etc.. I believe this will make running tests easier and more intuitive. The fact that different flavors of mochitest exist will become a background implementation detail. Instead, an emphasis will be placed on running directories of tests, or tests related to certain features. The knowledge of which test belongs to which flavor will no longer be required, but of course the ability to run specific flavors will still be there for those who need it. The described behaviour for |mach mochitest| above, already exists today. This bug is about making it the defacto way to run mochitests (maybe aside from |mach test|). This bug will also add b2g and android support to |mach mochitest|. Exceptions to this will be robocop, webapprt-chrome and webapprt-content which for technical reasons will not be rolled into |mach mochitest| (for now). Please let me know if you have any questions or concerns, -Andrew [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1164597 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
