Hi,
In the next few weeks, there is going to be a reduction in the number of
our memory allocator wrappers/functions, for essentially the following
reasons:
- we have too many of them,
- developers rarely know which one to use, which results in:
- developers often make mistakes[1]
This started to
Crashtests are a very low proportion of our overall automation burden. We
also gain something from running a "tricky situation" in as many different
configurations (opt and debug) as possible, since we may catch bugs other
than the one we had in mind when writing the crashtest.
So I think we shoul
It seems we generally add crashtests even for softening assertions to
non-crash ones. I suggest that we mark those kind of crashtests debug build
only, so that testing machines don't need to waste time on testing them on
release build where they never crash.
I'm not sure how many crashtests are si
Having followed the "Intent to implement" emails for a while, and
noticing that there was already an email template for it on wikimo:
https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement
I went ahead and wrote up a page about this practice, along with links
to Blink/MS equivale
>From the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1138658
This will be on by default in 39 right?
Do we have any nice example pages to show it off?
Being able to use CSS Snap Points has also come up in recent
#indiewebcamp discussions, so FWIW, there are also independent web
developers
Bobby Holley writes:
> On Mon, Mar 30, 2015 at 10:54 AM, Chris Peterson
> wrote:
>
>> On 3/29/15 3:35 PM, smaug wrote:
>>
>>> Having the one commit in the blame doesn't really matter. Often one
>>> needs to go to the first commit of the code anyway.
>>>
>>
>> Is there an hg or git equivalent to
Le 31 mars 2015 à 08:14, James Graham a écrit :
> If you just mean that the specifics of this analysis have all been done
> in Blink then yes,
That's all. That was context.
> very general lessons in there about the perf-destroying things that authors
> do, which provides an indication of where
On 30/03/15 23:55, Karl Dubost wrote:
>
> Le 31 mars 2015 à 07:43, James Graham a écrit :
>> There is also a view with some extra comments at [1] which are worth
>> reading.
>>
>> [1]
>> https://docs.google.com/document/d/1K-mKOqiUiSjgZTEscBLjtjd6E67oiK8H2ztOiq5tigk/view#
>
>
> And to not forge
Le 31 mars 2015 à 07:43, James Graham a écrit :
> There is also a view with some extra comments at [1] which are worth
> reading.
>
> [1]
> https://docs.google.com/document/d/1K-mKOqiUiSjgZTEscBLjtjd6E67oiK8H2ztOiq5tigk/view#
And to not forget the title, if people missed the topic of that emai
On Tue, Mar 31, 2015 at 10:49 AM, Robert O'Callahan
wrote:
> This is a quick read and an interesting analysis of how various sites fail
> to achieve acceptable performance on mobile:
>
> https://docs.google.com/document/d/1K-mKOqiUiSjgZTEscBLjtjd6E67oiK8H2ztOiq5tigk/pub
>
One clear message: bloc
On 30/03/15 22:49, Robert O'Callahan wrote:
> This is a quick read and an interesting analysis of how various sites fail
> to achieve acceptable performance on mobile:
> https://docs.google.com/document/d/1K-mKOqiUiSjgZTEscBLjtjd6E67oiK8H2ztOiq5tigk/pub
There is also a view with some extra comment
This is a quick read and an interesting analysis of how various sites fail
to achieve acceptable performance on mobile:
https://docs.google.com/document/d/1K-mKOqiUiSjgZTEscBLjtjd6E67oiK8H2ztOiq5tigk/pub
Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao
On Mon, Mar 30, 2015 at 10:54 AM, Chris Peterson
wrote:
> On 3/29/15 3:35 PM, smaug wrote:
>
>> Having the one commit in the blame doesn't really matter. Often one
>> needs to go to the first commit of the code anyway.
>>
>
> Is there an hg or git equivalent to Perforce's "Time-Lapse View" tool?
On 3/29/15 3:35 PM, smaug wrote:
Having the one commit in the blame doesn't really matter. Often one
needs to go to the first commit of the code anyway.
Is there an hg or git equivalent to Perforce's "Time-Lapse View" tool?
It shows a global view of a file's blame history and you can visually
Since I've only had one response I'll assume interest in a DOM triage
meeting is pretty low. As such I don't think there will be much interest
in a strictly scheduled meeting and will instead be doing triage
sporadically on my own.
Please email me back if you'd like to join me so that I can tr
Mark, this was added as one of the use cases:
https://mozilla-ci-tools.readthedocs.org/en/latest/use_cases.html#case-scenario-3-retrigger-an-intermittent-job-on-a-changeset-until-hit
It requires adding monitoring of jobs through Pulse and being able to inspect
the structure log for matching the t
Hi Gijs,
I worked last quarter on a project that allows us to trigger jobs accross
revision ranges in various ways, trigger jobs multiple times or even create the
missing builds to trigger a test job.
https://mozilla-ci-tools.readthedocs.org/en/latest
Some of the use cases:
https://mozilla-ci-to
17 matches
Mail list logo
