On Mon, Oct 08, 2012 at 11:10:37PM -0400, Zack Weinberg wrote:
> On 2012-10-08 3:05 PM, Gregory Szorc wrote:
> >We now have a tool in mozilla-central that has a much better UX for
> >running tests (mach). It's not perfect yet, but it's getting there
> >(please write patches!).
> >
> >The build peer
On 09/10/12 17:37, Robert O'Callahan wrote:
> Which tests?
With 7 digits of float precision it fails:
* content/smil/test/test_smilCSSFromBy.xhtml
* layout/style/test/test_animations.html
* layout/style/test/test_bug399349.html
* layout/style/test/test_flexbox_layout.html
* layout/style/test/test
Because it requires you recall that factoid. It ends up being a bit of
oral tradition. Someone new to the project asks how to find a
regression range on inbound and you need to communicate this bit of
info. Normally if you catch a regression quickly inbound is a better
place to locate it. I find th
On Tue, Oct 9, 2012 at 10:16 AM, Anthony Jones wrote:
> This formats the float to 6 significant figures, however a float has 7.2
> significant figures[1]. A float can contain any integer up to 2^24.
> Anything more than 999,999 pixels shows in exponent format as 1e+6 and so
> on. Currently co-ord
On Mon, Oct 8, 2012 at 8:10 PM, Zack Weinberg wrote:
> On 2012-10-08 3:05 PM, Gregory Szorc wrote:
>
>> We now have a tool in mozilla-central that has a much better UX for
>> running tests (mach). It's not perfect yet, but it's getting there
>> (please write patches!).
>>
>> The build peers (or a
On 09/10/12 11:09, Nicholas Nethercote wrote:>
> But I do agree that it would be lovely to automate this.
+1 for automation. Cross-referencing is a machine's job.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/list
On 10/8/12 8:10 PM, Zack Weinberg wrote:
When I run tests locally I do so by hand, because I invariably require
more precise control over how the test suite is operating than the make
targets allow. (I have occasionally even needed to bypass runtest.py.)
I expect mach will have the same proble
On 2012-10-08 3:05 PM, Gregory Szorc wrote:
We now have a tool in mozilla-central that has a much better UX for
running tests (mach). It's not perfect yet, but it's getting there
(please write patches!).
The build peers (or at least a few of us) really don't like the make
targets to run tests be
> I suspect having the inbound changeset is useful for someone doing regression
> hunting (ie, looking between merges)?
It's the same hash on inbound and central, so I don't see why this
would matter. For example,
http://hg.mozilla.org/mozilla-central/rev/8ebfc639c69f
http://hg.mozilla.org/integ
On 10/8/12 11:09 AM, Kevin Brosnan wrote:
I agree with Gavin this makes reading a bug much simpler when it comes
to understanding where a patch has landed especially when backouts
occur. The information is added for other readers of the bug not the
developer of the patch.
I concur and dissent.
On 10/8/12 12:05 PM, Gregory Szorc wrote:
I'm writing this post to see what obstacles/resistance there are to
removing the make targets for running tests. Obviously a prerequisite is
having mach reach feature parity with the make targets. What other
concerns are there?
How about a comparison o
2012/10/8 Daniel Holbert :
> jgilbert points out that
> - NS_ALWAYS_INLINE is broken in other ways as well (does absolutely
> nothing on windows, even when paired with "inline").
Yes, see https://bugzilla.mozilla.org/show_bug.cgi?id=697810
We had been working around these problems by having our
jgilbert points out that
- NS_ALWAYS_INLINE is broken in other ways as well (does absolutely
nothing on windows, even when paired with "inline").
- there exists MOZ_ALWAYS_INLINE which does this right.
So, we should probably just get rid of NS_ALWAYS_INLINE, and replace its
uses with the new-an
On Mon, Oct 8, 2012 at 12:57 PM, L. David Baron wrote:
>
> At the very least, you need documentation on where to get or find
> mach and what directory to run it in.
>
> (I don't seem to have it right now, and I'm not sure if the mach
> you're talking about is what I'd get if I 'sudo apt-get instal
On Mon, Oct 8, 2012 at 8:05 AM, Gavin Sharp wrote:
>
> You should feel free to break the convention if the only people
> impacted are you an njn and you're both fine with it.
FWIW, I'm not fine with it :) I like knowing when a patch lands on
inbound. I also like having the full paper trail in t
I've been tracking down an issue that led me to
nsROCSSPrimitiveValue::GetCssText()
case CSS_PX :
{
float val =
nsPresContext::AppUnitsToFloatCSSPixels(mValue.mAppUnits);
tmpStr.AppendFloat(val);
tmpStr.AppendLiteral("px");
break;
}
This formats
On Mon, Oct 08, 2012 at 12:05:58PM -0700, Gregory Szorc wrote:
> We now have a tool in mozilla-central that has a much better UX for
> running tests (mach). It's not perfect yet, but it's getting there
> (please write patches!).
>
> The build peers (or at least a few of us) really don't like the m
On Monday 2012-10-08 12:40 -0700, Gregory Szorc wrote:
> On 10/8/12 12:17 PM, L. David Baron wrote:> On Monday 2012-10-08 12:05
> > Updating the documentation on how to run the tests (which is spread
> > across a bunch of places) is extremely important. You should also
> > expect to get more feedb
On 10/8/12 12:34 PM, Jesper Kristensen wrote:
Before you deprecate the make targets, it would be nice if mach actually
works and there is documentation for it.
For documentation, one of the fundamental features of mach is it should
be self-documenting. You should be able to run |mach help| an
On 10/8/12 12:17 PM, L. David Baron wrote:> On Monday 2012-10-08 12:05
> Updating the documentation on how to run the tests (which is spread
> across a bunch of places) is extremely important. You should also
> expect to get more feedback once that happens.
Well, one of the benefits of mach is y
Den 08-10-2012 21:05Gregory Szorc skrev:
We now have a tool in mozilla-central that has a much better UX for
running tests (mach). It's not perfect yet, but it's getting there
(please write patches!).
The build peers (or at least a few of us) really don't like the make
targets to run tests becau
On Mon, Oct 8, 2012 at 9:05 PM, Gregory Szorc wrote:
> I'm writing this post to see what obstacles/resistance there are to removing
> the make targets for running tests. Obviously a prerequisite is having mach
> reach feature parity with the make targets. What other concerns are there?
Maintainin
> What other concerns are there?
It took me a not insubstantial amount of effort to develop expertise
with our baroque and only half-documented make commands, and while I'm
happy to believe that the new ones are better, that still doesn't make
the switch simple.
If we want to deprecate the make
On Mon, Oct 8, 2012 at 12:05 PM, Gregory Szorc wrote:
> We now have a tool in mozilla-central that has a much better UX for
> running tests (mach). It's not perfect yet, but it's getting there (please
> write patches!).
>
> The build peers (or at least a few of us) really don't like the make
> ta
On Monday 2012-10-08 12:05 -0700, Gregory Szorc wrote:
> I'm writing this post to see what obstacles/resistance there are to
> removing the make targets for running tests. Obviously a
> prerequisite is having mach reach feature parity with the make
> targets. What other concerns are there?
Updatin
We now have a tool in mozilla-central that has a much better UX for
running tests (mach). It's not perfect yet, but it's getting there
(please write patches!).
The build peers (or at least a few of us) really don't like the make
targets to run tests because they are awkward, both to maintain a
I agree with Gavin this makes reading a bug much simpler when it comes
to understanding where a patch has landed especially when backouts
occur. The information is added for other readers of the bug not the
developer of the patch.
Kevin Brosnan
On Mon, Oct 8, 2012 at 5:56 AM, Gavin Sharp wrote:
Our weekly DOM bindings meetings continue on Monday October 8th at 12:30 PM
PDT.
Meeting details:
* Monday, October 8, 2012, 12:30 PM PDT
* Conference room 7-N, San Francisco office, 7th floor.
* Dial-in Info:
- Vidyo room: SFO-7N
- In office or soft phone: extension 92
- US/INTL: 650-903-0800
James Newell schrieb:
Am I right to assume from https://bugzilla.mozilla.org/show_bug.cgi?id=778858
that the OOP setting is enabled by default now? I manually added the setting
from the previously mentioned bug just in case and saw no change in behaviour.
I didn't even see the plugin container
On Mon, Oct 8, 2012 at 3:42 PM, Justin Lebar wrote:
> I don't feel like it's /always/ important.
>
> On a bug that njn and I are the only ones watching and which gets
> landed on m-i over the weekend, it's not at all clear to me that
> anyone is hurting for lack of an explicit notification that th
njn didn't want to call me out as the culprit here, but I'm happy to
own up to it. :)
> "Pushed to inbound" is an important status to have indicated in the bug,
I don't feel like it's /always/ important.
On a bug that njn and I are the only ones watching and which gets
landed on m-i over the we
On Monday 2012-10-08 20:03 +1100, Nicholas Nethercote wrote:
> In https://wiki.mozilla.org/Tree_Rules/Inbound, one of the steps under
> "Please do the following after pushing to inbound" is:
>
> "Add the inbound changeset URL to the bug. If there are multiple
> patches on the bug and you are not p
I disagree. "Pushed to inbound" is an important status to have
indicated in the bug, and the best way to do that is to include the
inbound changeset URL (even though it will be the same revision when
it gets to m-c, it's useful to know where it is until it gets there).
It also helps with backouts,
Hi,
In https://wiki.mozilla.org/Tree_Rules/Inbound, one of the steps under
"Please do the following after pushing to inbound" is:
"Add the inbound changeset URL to the bug. If there are multiple
patches on the bug and you are not pushing all of them, please
indicate which one(s) you pushed (eg: u
34 matches
Mail list logo
