Re: running tests on the build farm in HiDPI mode

On Apr 9, 2013, at 1:02 PM, Cameron McCormack wrote: > It might be sufficient just to set layout.css.devPixelsPerPx = 2, and not > actually run on HiDPI hardware. Note that HiDPI can also be tested generally without HiDPI hardware on OS X: https://developer.apple.com/library/mac/#documentation

[devtools] Ready to replace the Error Console: the Browser Console landed

Hello everyone! Yesterday we landed a couple of changes for the Web Console [1] and we also included the new Browser Console, bug 587757 . [2] To try it please set devtools.chrome.enabled to |true| in about:config. Then you can go to the *W

Re: [devtools] Ready to replace the Error Console: the Browser Console landed

On 4/10/2013 12:05 PM, Mihai Sucan wrote: If anyone has any concerns about us replacing the Error Console, please shout loud and clear! We plan to do the aforementioned steps to replace the Error Console in the current release cycle, maybe in bug 602006

reorganizing some test directories

There are a couple common directory structures used for storing tests in the tree: 1) /tests 2) /tests/ I have a series of patches which will move most of the directory structures from #1 to a format of #2. This means we would see: /tests/mochitest /tests/browser /tests/chrome I have noticed t

Re: [devtools] Ready to replace the Error Console: the Browser Console landed

Hello Joshua! Le 10/04/2013 20:41, Joshua Cranmer 🐧 a écrit : On 4/10/2013 12:05 PM, Mihai Sucan wrote: If anyone has any concerns about us replacing the Error Console, please shout loud and clear! We plan to do the aforementioned steps to replace the Error Console in the current release cycl

Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

Hi Everyone, Right now, when a landing occurs, my understanding is that we're typically setting the target milestone field to what Firefox release the code lands on if it lands on trunk. If a patch is uplifted, then the status flag is set appropriately for the target Firefox release. However

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

> * The need for a particular team to track the concept of "We would > like to get this fixed in this Firefox release." Some teams I've > worked with have considered using the target milestone field here, > but that collides with the trunk management definition, which often > causes content

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

Right now the status and tracking flags for a version get hidden when that version becomes old. If we switched away from using target-milestone, we'd need to prevent this from happening. On Wed, Apr 10, 2013 at 4:53 PM, Alex Keybl wrote: >> * The need for a particular team to track the concept o

Layers Refactoring Landing

Hey all, Last night we've landed the layers refactoring. This was a very large patch that had to be landed in one go. At the moment we are aware (and not completely surprised), that the first couple of regressions due to the refactoring have been found. We are working very hard with the entire

Re: reorganizing some test directories

With the fix to bug 844288 gtest will also need their own directory. I was planning on allowing users to use /tests folder for their tests but to go in line with this upcoming change I'll update my patches and suggest that anyone who adds gtest to use /tests/gtest to conform with this new style. I

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

Comments inline. Sincerely, Jason Smith Desktop QA Engineer Mozilla Corporation https://quality.mozilla.com On 4/10/2013 2:19 PM, Justin Lebar wrote: Right now the status and tracking flags for a version get hidden when that version becomes old. If we switched away from using target-milestone

Re: [devtools] Ready to replace the Error Console: the Browser Console landed

Mihai Sucan wrote: let console = Cu.import("resource://gre/modules/devtools/Console.jsm", {}).console; Why not just import Console.jsm directly? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: reorganizing some test directories

On 4/10/2013 2:42 PM, Benoit Girard wrote: > With the fix to bug 844288 gtest will also need their own directory. I was > planning on allowing users to use /tests folder for their tests > but to go in line with this upcoming change I'll update my patches and > suggest that anyone who adds gtest to

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

On 4/10/2013 1:38 PM, Jason Smith wrote: > Hi Everyone, > > Right now, when a landing occurs, my understanding is that we're > typically setting the target milestone field to what Firefox release > the code lands on if it lands on trunk. If a patch is uplifted, then > the status flag is set appropr

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

> On 4/10/2013 2:19 PM, Justin Lebar wrote: >> Right now the status and tracking flags for a version get hidden when >> that version becomes old. If we switched away from using >> target-milestone, we'd need to prevent this from happening. > > Ah, good point. Didn't think of that initially. That

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

On 4/10/2013 5:14 PM, Gregory Szorc wrote: I don't really have much to say on the specifics of this post other than a simple question: why don't we have a checkin hook or bot automatically update Bugzilla flags when changesets are pushed? This would save developer time and would reduce the error

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

That's a good idea. Should we file a bug to do this? Sincerely, Jason Smith Desktop QA Engineer Mozilla Corporation https://quality.mozilla.com On 4/10/2013 5:14 PM, Gregory Szorc wrote: On 4/10/2013 1:38 PM, Jason Smith wrote: Hi Everyone, Right now, when a landing occurs, my understanding

Annotating Commits

Mercurial and Git both support the ability to attach arbitrary key-value string data to commits. There is an abundance of awesomeness that could be realized if we started storing [machine readable] information inside our commits (not inside the commit messages). Here are some examples: * Who the r

Re: Annotating Commits

On 11/04/13 15:23, Gregory Szorc wrote: > Mercurial and Git both support the ability to attach arbitrary key-value > string data to commits. There is an abundance of awesomeness that could > be realized if we started storing [machine readable] information inside > our commits (not inside the commit

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

On 4/10/13 1:53 PM, Alex Keybl wrote: Knowing this, why not consider just using the status-flags purely to track landings and let the team determine how to use target milestone? Also, why not set the status-flag in general for the appropriate Firefox release when a patch lands on trunk? The di

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

> why don't we have a checkin hook or bot automatically > update Bugzilla flags when changesets are pushed? Auto-adding the comment containing the link to hg.mozilla.org would be great too :) Nick ___ dev-platform mailing list dev-platform@lists.mozilla