On Mon, Oct 12, 2020 at 10:05 AM Ricky Stewart wrote:
> Hello everyone,
>
> If you don't write Python code in mozilla-central, you can stop reading
> now.
>
> On October 19, 2020 we will be officially adopting the black Python style
> for all our Python code in mozilla-central.
>
> black (https:/
On Wed, Sep 16, 2020 at 5:10 AM Eric Rescorla wrote:
> I certainly have some sympathy for this, but I'm not sure that it needs to
> be
> addressed via tools. What I would generally expect in cases like this is
> that the reviewer says "why isn't there a test for X" and the author says
> "for reas
On Tue, Sep 15, 2020 at 8:03 AM Brian Grinstead
wrote:
> (This is a crosspost from firefox-dev)
>
> Hi all,
>
> We’re rolling out a change to the review process to put more focus on
> automated testing. This will affect you if you review code that lands in
> mozilla-central.
>
> ## TLDR
>
> Revie
In case like me you've had these files staring back at you whenever you do
git status or whatever the equivalent is in hg, according to discussion in
bug 1630362, as of about May 7th you can delete these files and they won't
come back.
Andrew
___
dev-pla
On Thu, Apr 9, 2020 at 6:51 PM Sarah Clements wrote:
> Hello,
>
> As part of maintenance work and performance improvements to Treeherder,
> we're making changes to some of the data that's stored in our database. On
> *April
> 30th*, we will no longer be retrieving uploaded artifacts for jobs and
In times of old, you could declare an XPIDL interface that didn't inherit
from nsISupports, as long as it only had constants in it. I'm not sure why
it was really such a burden to make it inherit from nsISupports. Anyways,
it appears that our de-COM efforts have proceeded far enough that this
featu
On Wed, Oct 2, 2019 at 2:35 PM Geoff Lankow wrote:
> Hi all, I need some advice.
>
> I'm trying to enable Mochitest on debug builds of Thunderbird. It works
> fine, except for the leak check, which finds a number of leaked windows
> and docshells. Obviously we don't want to leak these things, but
On Tue, Sep 10, 2019 at 4:55 PM Dave Townsend wrote:
> On Mon, Sep 9, 2019 at 6:01 PM Jeff Walden wrote:
>
> > Those of you longer in the tooth may remember Firefox was successfully
> > exploited in Pwn2own 2012...and we didn't have to lift a finger to fix
> it.
> > We already had -- in the Fire
On Sat, Aug 10, 2019 at 7:15 AM wrote:
> I have started to learn about IPDL and am reading IPDL Tutorial (
> https://developer.mozilla.org/en-US/docs/Mozilla/IPDL/Tutorial). It looks
> like the document is old and needs some edits, but this is an area I'm
> still learning so I want to make sure:
On Fri, Jul 5, 2019 at 7:50 PM Masatoshi Kimura
wrote:
> On 2019/07/06 6:54, Andrew McCreight wrote:
> >> Here's an example of a crash report with DOMFissionEnabled:
> >>
> https://crash-stats.mozilla.org/report/index/dac0a91a-ad57-4446-9a82-505a80190705#tab-
On Fri, Jul 5, 2019 at 1:12 PM Andrew McCreight
wrote:
> I landed bug 1560977 a few days ago, so you can now see in a crash report
> if Fission was enabled. If it was, the "meta data" tab will have a value of
> 1 for DOMFissionEnabled. The behavior is modeled after
I landed bug 1560977 a few days ago, so you can now see in a crash report
if Fission was enabled. If it was, the "meta data" tab will have a value of
1 for DOMFissionEnabled. The behavior is modeled after DOMIPCEnabled which
indicates when e10s is enabled. There is no explicit indicator if Fission
I just landed bug 1550770 which makes it an error to have an XPIDL
interface with a [notxpcom] method or attribute that is not [builtinclass].
Previously, we would just silently make it builtinclass. The new approach
makes it easier to see if an interface is really builtinclass or not, but
if you h
On Tue, Mar 12, 2019 at 3:55 AM Sylvestre Ledru
wrote:
> With this change, we are going to extend Bugzilla to add a new field with
> three new values:
>
>-
>
>Defect - an issue in one of our products
>-
>
>Enhancement - a new feature or an improvement
>-
>
>Task - a develo
On Fri, Nov 30, 2018 at 10:00 AM wrote:
> Now that all of mozilla-central is been migrated to use clang-format
> automated code formatting, the question of what should happen with editor
> modelines at the top of files should be considered.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=clang-f
On Thu, Nov 29, 2018 at 8:44 AM Honza Bambas wrote:
> OTOH, if the changes are only whitespace changes, maybe there is some
> way `patch --ignore-whitespace --fuzz N` could apply the patches. Then
> just re-format and your patches are OK.
>
The changes that clang-format makes include things lik
gt; On Tue, Oct 2, 2018 at 9:30 AM Andrew McCreight
> wrote:
>
>> I've landed bug 1494765, which allows you to do assignments between
>> nsCOMPtrs for classes that are related by subtyping.
>>
>> For instance:
>>
>> class A { ... ];
>> class B :
I've landed bug 1494765, which allows you to do assignments between
nsCOMPtrs for classes that are related by subtyping.
For instance:
class A { ... ];
class B : public A { ... };
nsCOMPtr b = ...;
nsCOMPtr a = b; // this works now
This is a step towards bug 1493226, which is going to staticall
On Wed, Sep 19, 2018 at 5:44 PM Kris Maglione wrote:
> On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote:
> >So, I don't think we need to do anything fancy with forking - we'd just
> >need to capture stacks and send them via telemetry rather than as a crash
> >report. This was the idea
On Sun, Jul 29, 2018 at 7:35 PM, Anthony Jones wrote:
> I'm chuffed to announce that Web Replay has finally made its way into
> nightly. It brings tardis like functionality (or perhaps rr like) to
> Firefox Devtools, enabling recording and replaying of tab behavior, and
> best of all, stepping ba
as dropped 1.1-1.9MB.
>>
>> Particular credit goes to:
>>
>> * Eric Rahm added an AWSY test suite to track base content process memory
>>(https://bugzil.la/1442361). Results:
>>
>> Resident unique: https://treeherder.mozilla.org
>> /perf.html#/graphs
On Wed, Jul 11, 2018 at 5:42 AM, David Bruant wrote:
>
>
> * Andrew McCreight created a tool for tracking JS memory usage, and
>> figuring
>> out which scripts and objects are responsible for how much of it
>> (https://bugzil.la/1463569).
>>
> How often i
For people who aren't subscribed to dev-firefox, be aware that open bugs
that haven't been modified in a year have been set to "inactive" without
any bugmail being generated, in bug 1445054. It is probably better to that
thread rather than creating a new parallel thread on this list...
Andrew
--
A few years ago I came up with an approach for using a combination of cycle
collector logs and DMD (which tracks all live blocks of heap allocated
memory) to investigate leaks of refcounted objects. I've only had to use it
about a half dozen times (most recently in bug 1451985), but it is very
hand
On Thu, Apr 19, 2018 at 12:53 PM, Gijs Kruitbosch
wrote:
> Dumb question because I don't do this very often - sorry!
>
> I am intending to async-ify a sync JS-implemented idl-defined API (which
> currently returns an unsigned long), that has a few C++ consumers. I was
> thinking the simplest solu
I recently landed bug 1438688, which makes it so that we don't ship XPT
files any more, so they don't need to be added to a package-manifest.in
file. (Instead, the XPT information is compiled into the binary.) I think
it'll give you an error if you add it anyways, but I haven't tested it. We
still
Following up on my previous post, I have just landed (in bug 1432992) the
removal of most of the definitions of Ci, Cr, Cc, and Cu. This touched
almost 2000 files, so it may affect your patches, but hopefully rebasing is
easy. Thank you to Florian for reviewing a nearly-unreviewable patch and
sugg
Bug 767640 just merged to mozilla-central. This patch makes it so that Ci,
Cr, Cc, and Cu are automatically defined in any chrome scope that has a
Components object. Rejoice, because you no longer need to add "var Ci =
Components.interfaces" into every file.
I have a followup bug, bug 1432992, tha
On Wed, Jan 10, 2018 at 6:22 AM, Romain Testard wrote:
> Some enterprises may indeed find that enabling site isolation is worth the
> trade-offs (memory usage seems to be the main one on Chrome's
> implemenation).
>
Just to be clear here, we do not support the same kind of site isolation
that Ch
On Fri, Dec 15, 2017 at 9:38 AM, James Graham
wrote:
> Following the summary of what we achieved in wpt in the last year, I'd
> like to solicit input from the gecko community to inform the
> priorities of various pieces of wpt work for the next year.
>
> In order to maximise the compatibility ben
I just landed a patch for bug 1409115 that fixes a leak where a global data
structure (some per-process service worker queue) holds alive a DOM
promise, which ends up leaking the window forever. Fundamentally, holding
alive a DOM promise, which holds alive its window, from a data structure
that is
I half-heartedly keep an eye on intermittent leaks, so I can more active in
looking at them. We'll need more logging for them to be actionable, but I
guess the high frequency ones are easier to catch.
Andrew
On Thu, Oct 26, 2017 at 10:20 AM, Geoffrey Brown wrote:
> Some of our most troublesome
On Tue, Sep 19, 2017 at 8:49 AM, Eric Rescorla wrote:
> Generally no, but this is an unfortunate consequence of Mozilla's decision
> a while ago to pick a VCS which has not turned out to be the dominant
> choice (not placing blame here, but I think it's clear that's how it's
> turned out). The re
On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta wrote:
> I've tried using cinnabar a couple of times now and the last time I
> tried, this was the dealbreaker for me. My worfklow often involves
> moving a branch from one machine to another and the extra hassle that
> results from mismatched SHAs
s
> only a getter", and "ReferenceError: assignment to undeclared variable",
> and if you see any, file bugs blocking bug 1394556.
>
> 2) Andrew McCreight has been working on changing the component loader to
> load most modules and components into a single global[3], with each
On Thu, Sep 7, 2017 at 5:07 AM, Emilio Cobos Álvarez
wrote:
> Hi,
>
> I have a coding style question which I don't see addressed in the coding
> style page.
>
> Given there have been a few threads lately on coding style, I guess I
> should just ask.
>
> We have a lot of meaningless argument names
Just use NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION instead.
These have been identical for years, so I just removed the _INHERITED
variant in an attempt to make the CC macros a little simpler to deal with,
in bug 1391005.
Andrew
___
dev-platform mailing li
On Thu, May 25, 2017 at 4:03 PM, wrote:
> On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote:
> > On 2017-05-25 5:31 AM, Ehsan Akhgari wrote:
> > > On 05/19/2017 02:44 PM, Gregory Szorc wrote:
> > >> `mach build` attempts to parse compiler warnings to a persisted
> > >> "database.
On Mon, May 22, 2017 at 4:45 PM, Karl Tomlinson wrote:
> Andrew McCreight writes:
>
> > On Fri, May 19, 2017 at 7:38 PM, Nicholas Nethercote <
> n.netherc...@gmail.com
> >> wrote:
> >
> >> There's also a pre-processor constant that we define in
>
On Fri, May 19, 2017 at 7:38 PM, Nicholas Nethercote wrote:
> There's also a pre-processor constant that we define in Valgrind/ASAN/etc.
> builds that you can check in order to free more stuff than you otherwise
> would. But I can't for the life of me remember what it's called :(
>
NS_FREE_PERMA
On Fri, May 12, 2017 at 11:34 AM, Ted Mielczarek wrote:
> On Fri, May 12, 2017, at 10:45 AM, Sylvestre Ledru wrote:
> > Would it be possible to add a check like:
> > "You haven't updated your local configuration since XX days, please
> > consider running
> > mach bootstrap ?"
>
> We've had mach p
This was posted on mozilla.tools yesterday but doesn't seem to have made it
to dev.platform. It is likely to be of interest to many people on this
list. Note the comment "If you have questions or concerns beyond those
addressed below, please
use the mozilla.tools group and/or #phabricator on IRC an
I updated my tree this morning and did a build, and I ended up with a new
untracked
nsILayoutHistoryState.h file. Be sure to not accidentally commit it.
I deleted the file, and then had to do a clobber build to fix everything.
I filed bug 1351461 for the clobber issue or whatever it is.
_
Note: this only affects you if you write tests in the
ipc/ipdl/test/ipdl/error/ directory.
In bug 1319620, I added checking of expected failures for IPDL error unit
tests. This will ensure that changes like renaming IPDL keywords won't make
the error tests silently start failing for the wrong reas
On Wed, Mar 22, 2017 at 6:00 PM, Nicholas Nethercote wrote:
> Do we have a clear definition of "content process"? I.e. does/will it
> include:
>
> - GMP processes (no?)
> - GPU process (probably not?)
> - file:// URL processes (probably should?)
> - Web Extensions processes (probably should?)
> -
If you are seeing this error when you try to do |git mozreview push|,
update your version-control-tools. Then you'll see a different error. Work
related to that is being looked at in
https://bugzilla.mozilla.org/show_bug.cgi?id=1338530
Andrew
___
dev-pla
On Thu, Mar 9, 2017 at 1:55 PM, Nicholas Alexander
wrote:
> On Thu, Mar 9, 2017 at 1:48 PM, Boris Zbarsky wrote:
>
> > On 3/9/17 4:35 PM, Eric Rescorla wrote:
> >
> >> I'm in favor of good commit messages, but I would note that current m-c
> >> convention really pushes against this, because peop
On Mon, Mar 6, 2017 at 4:45 PM, Eric Rahm wrote:
> I'd suggest looking at the memory overhead of Chrome's individual processes
> as compared to ours, it's pretty impressive. My blog posts on our own e10s
> memory usage [1] and comparison to other browsers [2] have further details.
> I'm planning
On Fri, Mar 3, 2017 at 4:15 PM, Nicholas Nethercote
wrote:
> Hi,
>
> I want to understand all the different processes that we can and will have
> in Firefox. Here's a list I constructed off the top of my head.
>
> - main process
>
> - content process(es): 1 on release for most users; 2 on Nightly
Last I looked, we didn't have any tests for VRFrameData, FWIW (bug
1317258). I see some now under servo/ but presumably we don't run those.
Maybe I'm missing some.
It would also be good to make sure our internal fuzzers are fuzzing these
APIs to at least catch basic errors.
Andrew
On Wed, Mar 1,
In bug 1316755, I'm working on removing support for the IPDL keywords
spawns, opens and bridges. These have been superseded by endpoints, a more
general mechanism for starting up IPDL actors. The only drawback is that
endpoints don't allow for static analysis of the relationships between
processes,
On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky wrote:
> If you want to get started before that, please make sure to
>> file a bug on what you're doing before you start. That should avoid
>> duplicating work.
>>
>
> Is there an overall tracking bug people could check to see which things
> are alrea
In bug 1308652, I'm planning on removing about:bloat. It disables XPCOM
leak tracking while it is running, so running it can cause false negative
leaks (bug 1271182). I don't think anybody uses it much any more, so I'm
going to remove it.
Andrew
___
dev-
You could also just file things like that in the corresponding component,
and maybe create some kind of meta bug for gdb hooks. So debugging for
nsTArray would be filed in XPCOM, etc. I think that's the way it works for
Javascript engine related debugging hooks. Failing that, having the nested
gdb
On Fri, Sep 2, 2016 at 12:11 PM, Ryan VanderMeulen wrote:
> On 9/2/2016 2:56 PM, Andrew McCreight wrote:
>
>> In DOM triage, we've just set up our list to not include bugs with the
>> keyword intermittent failure. Ideally, we'd see intermittent failures that
>>
In DOM triage, we've just set up our list to not include bugs with the
keyword intermittent failure. Ideally, we'd see intermittent failures that
have a high rate, but given that sheriffs keep an eye on oranges, they can
look for somebody to fix frequent ones as needed.
On Fri, Sep 2, 2016 at 11:4
On Fri, Aug 26, 2016 at 8:16 PM, Gregory Szorc wrote:
> What I'm trying to say is thank you for reminding me to implement the
> hook. And congratulations on likely being the last person to perform a case
> only rename on the repo.
>
Sarcastic commentary on an innocent mistake is not helpful.
Searchfox works pretty well for blame including the CVS history, including
large files that github won't show you.
On Thu, Aug 25, 2016 at 12:09 PM, Philip Chee wrote:
> On 16/09/2015 01:01, smaug wrote:
> > On 09/15/2015 06:53 PM, Boris Zbarsky wrote:
> >> On 9/15/15 11:11 AM, Ben Hearsum wrote
We regularly run AddressSanitizer and Valgrind on mozilla-central, so it
seems likely this is Thunderbird specific. Please file security bugs in
bugzilla with any reports you have found.
Andrew
On Thu, Aug 25, 2016 at 10:59 AM, ISHIKAWA,chiaki
wrote:
> Hi,
>
> I occasionally check C-C TB by run
I'm not sure of the particulars, but I believe ccache doesn't share the
results between two object directories unless you set it up explicitly to
use relative paths. Or something like that.
https://ccache.samba.org/manual.html#_compiling_in_different_directories
On Fri, Aug 19, 2016 at 3:45 PM,
On Sun, Jul 10, 2016 at 7:29 PM, Martin Thomson wrote:
> Is now the right time to start talking about retiring checkin-needed,
> or is it still heavily used?
>
It is useful for anybody who doesn't use MozReview. FWIW I see 14 bugs with
it set right now.
>
> On Sat, Jul 9, 2016 at 4:58 AM,
On Thu, Jun 30, 2016 at 8:41 AM, Aaron Klotz wrote:
> Did the now-defunct exit(0) project ever come up in this discussion?
>
> See bugs 662444 and 826143. This was a perf team project back in the
> Snappy days where the objective was to write important data to disk ASAP,
> then exit(0) without do
On Wed, Jun 22, 2016 at 1:05 PM, Henri Sivonen wrote:
> Now that I'm looking at the hand-written notes that I made in the
> meeting, I notice that the above paragraph fails to say how the
> AddRef, Release and associated cycle collection-related calls are
> routed from C++ to Rust or from Rust to
blassey landed a patch to suggest that users submit unsubmitted crash
reports. This is going to make various kinds of crashes, like shutdown
crashes, grossly overrepresented in the crash-stats "Top Crashers" list.
You probably want to use "By build date" instead of the default "By report
date" for
On Fri, Jun 3, 2016 at 6:57 AM, Ted Mielczarek wrote:
> BugHunter[1] attempts to reproduce crashes from crash-stats by loading
> the URLs from the crash reports, which is sometimes successful.
>
Of note, BugHunter also uses both debug and AddressSanitizer builds, which
occasionally turns up some
On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote wrote:
> If you use your favourite source code search tool to look for
> "Shutdown too long", you'll find that this crash is occurring in
> toolkit/components/terminator/nsTerminator.cpp. For example, here's a
> DXR link:
>
Sure, you can indiv
On Mon, May 30, 2016 at 11:22 PM, Nicholas Nethercote <
n.netherc...@gmail.com> wrote:
> 6 MOZ_RELEASE_ASSERT(pi->mInternalRefs < pi->mRefCount) (Cycle
> collector found more references to an object than its refcount)509
> 0.04 %
>
That's bug 1266882.
15 MOZ_RELEASE_ASSERT(aRefCount !=
On Thu, May 19, 2016 at 4:09 PM, Matthew N. wrote:
> As a reminder, the nice thing about pushPrefEnv is that the pref changes
> are reverted at the end of the test file which avoids them leaking into
> other tests unintentionally.
>
Another good thing about it is that set*Pref isn't actually syn
On Thu, May 19, 2016 at 8:04 AM, Ben Kelly wrote:
> 3) Supports async pipe streams using a new PSendStream actor from
> *child-to-parent*. I have plans to add support for parent-to-child, but I
> don't have a consumer yet and we need to figure out some issues with
> PBackground targeting worker
On Fri, May 13, 2016 at 1:02 PM, wrote:
> Why do you developers keep insisting breathlessly that 64-bit builds are
> memory hogs? I'm a power user who has 3 windows and 1,565 tabs open. I have
> a 4 GB laptop and a 16 GB desktop replaced a 6 GB desktop. I like to think
> that I use Firefox close
Thank you for opening a discussion thread rather than posting more in the
bug.
On Mon, May 9, 2016 at 11:23 AM, Tobias B. Besemer <
tobias.bese...@googlemail.com> wrote:
> Hi!
>
> Ignoring viewpoints of non-Mozilla-employees can't be the way to go for a
> OSS Project!
> The same mistake made Orac
Emma can correct me if I'm wrong, but I think she is using "Firefox" in the
non-jargony sense of the entire thing we're shipping in Firefox, including
Gecko. We've been using this system for a month or so in DOM. I think it
has been going well. Anybody who is interested can ask Andrew Overholt or I
status that is just confusing to bug
reporters, which discourages people from filing more bugs.
Andrew
>
> —
> - Milan
>
>
>
> > On Apr 1, 2016, at 11:16 , Andrew McCreight
> wrote:
> >
> > On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson
> > wrot
On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson
wrote:
> Anthony's Media Playback team has been using a simple and effective triage
> system without special tags. All open bugs in the Audio/Video Playback
> component are in one of four states at all times:
>
> * Priority P1 bugs should be fixed A
chrome to help avoid this
> confusion?
>
>
>>
>> On Thu, Mar 24, 2016 at 3:05 PM, Ehsan Akhgari
>> wrote:
>>
>>> On 2016-03-24 1:25 PM, Andrew McCreight wrote:
>>> > One potential sticking point is mochitest-chrome. It currently does not
>>
On Thu, Mar 24, 2016 at 9:15 AM, Andrew Halberstadt <
ahalberst...@mozilla.com> wrote:
> Bug 1243083 tracks enabling e10s by default when running tests locally.
> I intend to do this for as many harnesses as possible unless someone
> says otherwise.
Great!
[some text deleted]
One potential sti
On Wed, Mar 9, 2016 at 12:17 PM, Boris Zbarsky wrote:
> Just to satisfy my curiosity, what is AFL?
>
AFL is American Fuzzy Lop, a fuzzer that uses a combination of compiled-in
code coverage and genetic algorithms. http://lcamtuf.coredump.cx/afl/ It
has found a ton of errors in all sorts of progr
I'd also note that Google at least used to ship a similar kind of thing to
their Canary users a few times a week, called SyzygyASAN:
http://blog.chromium.org/2013/05/testing-chromium-syzyasan-lightweight.html
I haven't found a ton of detail about whether they still do it but that
blog post does s
49 PM, Andrew McCreight
wrote:
> I've updated my repository for my git-bz REST API branch:
> https://github.com/amccreight/git-bz-moz/tree/RestAPI
>
> I think everything is fixed now, so please try it out and let me know if
> you encounter problems or something seems slow. (There
On Thu, Sep 24, 2015 at 4:23 PM, Nicholas Nethercote wrote:
> On Thu, Sep 24, 2015 at 2:29 PM, Ehsan Akhgari
> wrote:
> > On 2015-09-24 1:41 PM, Sylvestre Ledru wrote:
> >>
> >> * Coverity, a proprietary tool with a great (but slow) web interface.
> >
> > Does anybody look at these regularly? I
[1]
[1]
https://groups.google.com/forum/#!topic/mozilla.dev.version-control/z9z9N7_vWiY
Andrew
On Tue, Sep 15, 2015 at 2:37 PM, Andrew McCreight
wrote:
> Apparently Bugzilla 2fa breaks the weird cookie authentication method that
> git-bz-moz and bzexport use. I think I've read that
On Thu, Sep 17, 2015 at 7:42 AM, Andrew McCreight
wrote:
>
>
> On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart
> wrote:
>
>> Good stuff!
>>
>> I hope you'll consider tracking AddRef's and Release's as well.
>>
>> I recently experimen
On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart wrote:
> Good stuff!
>
> I hope you'll consider tracking AddRef's and Release's as well.
>
> I recently experimented with that for a troubled RefCounted class [1], and
> it was very useful to find which AddRef didn't have its corresponding
> Releas
On Thu, Sep 17, 2015 at 6:50 AM, Ehsan Akhgari
wrote:
> git bz edit and git bz push don't work, but the rest should, so please file
>> issues at https://github.com/mozilla/git-bz-moz or email me if you notice
>> them. (Oh, I think setting reviewer flags for Firefox product bugs doesn't
>> work, i
Sorry, the command is actually |git bz apply 12345| as you probably figured
out.
Andrew
On Tue, Sep 15, 2015 at 2:40 PM, Andrew McCreight
wrote:
> Oh, and another thing I meant to mention that seems underused: if you are
> using git-bz-moz, the |git apply| command is pretty handy. You
, Sep 15, 2015 at 2:37 PM, Andrew McCreight
wrote:
> Apparently Bugzilla 2fa breaks the weird cookie authentication method that
> git-bz-moz and bzexport use. I think I've read that this is a bugzilla bug,
> but in the meanwhile I've been working on making git-bz-moz use the
&g
Apparently Bugzilla 2fa breaks the weird cookie authentication method that
git-bz-moz and bzexport use. I think I've read that this is a bugzilla bug,
but in the meanwhile I've been working on making git-bz-moz use the
Bugzilla backend of bexport, which is less hacky and supports using API
keys for
On Tue, Aug 4, 2015 at 9:33 AM, Jonas Sicking wrote:
> Fingerprinting doesn't seem useful if the fingerprint changes every
> few minutes as the battery level changes.
>
> I do agree that there are concerns that if the user has
> private-browsing pages and non-private-browsing pages open at the sa
Just so people know, ASan builds with GTK3 crash immediately on startup, so
you'll want to keep the gtk2 version as described below.
Andrew
On Wed, Jul 22, 2015 at 6:38 PM, Mike Hommey wrote:
> Hi,
>
> If you've followed the recent discussion in the "GTK3 linux builds"
> thread, this will come
Are we going to have tests for this? Does working include being properly
symbolicated?
But yes, it is extremely annoying to have failures without stacks. (See bug
1165469, which was only figured out once somebody reproduced the test
locally, because there was no stack.)
On Fri, Jul 10, 2015 at 9:
On Sun, Jun 28, 2015 at 7:55 PM, Vladan D wrote:
> I asked Avi to work on pausing GC/CC during scrolling in Q3 & Q4 2014. I
> still think it's relevant but process-per-tab will give some of the same
> benefits
>
Olli is working on creating some kind of unified scheduler for the giant
mess of GC
On Fri, Jun 19, 2015 at 8:27 PM, Nicholas Nethercote wrote:
> > Sat, Jun 20, 2015 at 2:16 AM, Gregory Szorc wrote:
> >
> > We can mass rewrite the tree. But unless
> > the tools to keep things consistent are easy and painless to use, this
> will
> > add chaos.
>
> Chaos? There are two distinct s
On Wed, Jun 17, 2015 at 3:53 AM, Mike Hommey wrote:
> What we currently have in the tree is essentially modelines for vim and
> emacs. But:
> - most vim installations have modelines disabled by default because of
> the security implications: https://lwn.net/Articles/20249/.
> - emacs has the sa
On Thu, Jun 4, 2015 at 2:49 AM, Jonas Sicking wrote:
> FWIW, I suspect it'll be hard to put a dent in the number of warnings
> that we emit unless we either change all instances of
> NS_ENSURE_SUCCESS(rv, rv) to use some other macro which doesn't warn,
> or unless we change NS_ENSURE_SUCCESS(rv,
I just landed a 1.2MB patch to fix C++ mode lines in dom/
As a reminder, the mode lines that should be used (in C++ files that are
properly 2-space indented) are:
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2
-*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
See more at:
On Tue, Apr 14, 2015 at 8:40 AM, Dave Townsend
wrote:
> Are the platform fields actually useful? Most bugs apply to all platforms
> and in the cases that don't it is normally clear from the bug conversation
> that it is platform specific. It seems like we rarely go an update the
> platform fields
On Fri, Apr 10, 2015 at 10:37 AM, Ehsan Akhgari
wrote:
> On 2015-04-10 12:33 PM, Andrew McCreight wrote:
>
>>
>>
>> On Fri, Apr 10, 2015 at 8:46 AM, Ehsan Akhgari > <mailto:ehsan.akhg...@gmail.com>> wrote:
>>
>> I would like to pr
I hacked up a crude script to collate the results from Gregory's
spreadsheet that collates the results across a subdirectory into sort of
useful results:
https://github.com/amccreight/gecko-components
From the spreadsheet, do "download as" and then "comma separate values" to
get the input format.
Is there any kind of existing code around that would look at the bugs for
the commits for the files in a directory and create some kind of count of
the components they were filed in? dom/ has something like 90
subdirectories, and it would be nice to be able to quickly get some kind of
census like
On Fri, Jan 30, 2015 at 2:08 AM, Tim Guan-tin Chien
wrote:
> Any support for Level 1 people for creating a patch-to-commit for
> attaching on Bugzilla?
> I tried :jlebar's moz-git-tools once but the exported patch was broken for
> hg.
>
The easiest way to attach a git patch to bugzilla is with
1 - 100 of 140 matches
Mail list logo