On 6/10/20 1:51 PM, Kartikaya Gupta wrote:
For those of you who like me are still running Ubuntu 16.04 LTS: the
minimum version of python required to build gecko got bumped from 3.5
to 3.6. As Ubuntu 16.04 doesn't offer python3.6 out of the box, you
may need to build it from source to get going a
Would it work to make a `mach try fuzzy --auto` or similar entrypoint,
where it brings up the fzf selector with the automatic set of tests as a
starting point?
On 5/6/20 6:55 AM, Andrew Halberstadt wrote:
Hello everyone,
A handful of us have been hard at work on an initiative to become smar
On 4/10/20 10:06 AM, Andrew McCreight wrote:
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 retri
See http://hotsphink.github.io/sfink-tools/doc/hazards.html for the
autogenerated HTML from my presentation on the static analysis. It
contains technical detail that I didn't cover, as well as details on
potential future analyses such as can-run-script and iterator
invalidation. Ask me anything
On 11/1/19 4:03 PM, Andrew Sutherland wrote:
On 11/1/19 4:39 PM, Kim Moir wrote:
On Nov 14, 2019, we intend to change the permissions associated with
Level
3 access to revoke direct push access to hg.mozilla.org on
mozilla-inbound,
mozilla-central, mozilla-beta, mozilla-release and esr repos.
On 10/28/19 9:17 PM, Marcos Caceres wrote:
On Tuesday, October 29, 2019 at 3:27:52 AM UTC+11, smaug wrote:
Quite often one has just a laptop. Not compiling tons of Rust stuff all the
time would be really nice.
(I haven't figured out when stylo decides to recompile itself - it seems to be
somew
I wrote another mini tool for my own purposes that I felt might be of
use to more people.
Periodically, I want to gather some sort of data from nontrivial browser
runs. So I'll stick some printfs into the code and do a try push -- most
often to run Talos jobs, since I naively think of them as
On 7/30/19 6:20 AM, Jan de Mooij wrote:
On Tue, Jul 30, 2019 at 1:51 PM ISHIKAWA,chiaki
wrote:
nsresult rv2
= NS_NewBufferedOutputStream(getter_AddRefs(mCopyState->m_fileStream),
mCopyState->m_fileStream.forget(), <=== It seems this can be nullptr in
clang-8 version???
On 4/1/19 11:36 AM, Brian Grinstead wrote:
Based on my own experience and discussions with others, the workflow for adding new
mochitests isn't great. Commonly, it looks like: "copy/paste a test in the same
directory, add the new test to the relevant manifest file, empty out the actual test
bi
If you're in an IRC channel with mrgiggles, the query "what is
0x806e000b?" will return the corresponding nsresult code(s), together
with any associated comments heuristically parsed from the ErrorList.py
source. The comments are sometimes helpful:
what is 0x804B0046?
0x804b0046 as nsresult
On 01/03/2019 10:07 AM, Justin Wood wrote:
on the specific proposal front I can envision us allowing tests to be run
on non-pgo builds via triggers (so never by default, but always
backfillable/selectable) should someone need to try and bisect an issue
that is discovered... I'm not sure if the co
On 01/03/2019 09:51 AM, Jonathan Kew wrote:
On 03/01/2019 16:17, jmaher wrote:
What are the risks associated with this?
1) try server build times will increase as we will be testing on PGO
instead of OPT
2) we could miss a regression that only shows up on OPT, but if we
only ship PGO and once
In theory, I would definitely prefer if all the code were auto-formatted
during regular development(*), but in practice the performance means
it's not as transparent as it needs to be -- I have noticed that since
enabling the format-source extension, rebasing my patch stacks is
significantly sl
On 11/29/2018 04:38 AM, Sylvestre Ledru wrote:
The experimentation with dom/media highlighted that we need an
efficient way to automatically rebase patches before the merge.
To achieve this, we updated the bootstrap process to include an
extension called hg formatsource.
This extension will au
On 11/28/2018 01:20 PM, James Graham wrote:
On 28/11/2018 20:15, Mark Côté wrote: * It's not obvious to people
that patches can't go up for review
without
a preexisting bug, and won't actually be reviewed unless they
specify a
reviewer in the commit message (or go into Phabrica
On 10/04/2018 03:45 PM, fantasai wrote:
Start here, at Mozilla's home page:
https://www.mozilla.org/
Give me steps to reproduce to find instructions for filing
a bug against Firefox. Ditto for up-to-date instructions
for building the source and submitting a patch.
(Don't send me links to the
On 08/31/2018 04:33 PM, Charles G Robertson wrote:
Hi,
I'm hoping someone can shed some light on this. I am trying to build Firefox
60.1ESR for s390x. When I install and run it crashes (segfault, core dump). See
the stack trace below.
It is crashing on this statement incrementing a member of t
On 07/12/2018 04:27 PM, Cameron McCormack wrote:
On Fri, Jul 13, 2018, at 6:51 AM, Kris Maglione wrote:
I actually have a patch sitting around with helpers to make it super easy to
use smart pointers as tagged pointers :) I never wound up putting it up for
review, since my original use case went
On 5/11/18 12:16 PM, Anthony Jones wrote:
On Friday, 11 May 2018 21:14:21 UTC+12, Sylvestre Ledru wrote:
Do we have a list of blockers (or meta bug) to make the switch on Linux?
We're already using clang for ASAN builds on Linux and passing tests. We'll
want to switch to clang on Linux pretty
awing attention to this, sfink.
This is likely to become more important as we continue to scale up our
parallelization with content processes and threads.
On 21 March 2018 at 14:54, Steve Fink mailto:sf...@mozilla.com>> wrote:
> Just to drive home a point, let's play
Just to drive home a point, let's play a game.
First, guesstimate what percentage of our users have systems with 2 or
fewer cores.
Then visit https://hardware.metrics.mozilla.com/#goto-cpu-and-memory to
check your guess.
(I didn't say it was a *fun* game.)
On 03/20/2018 06:49 AM, Henri Sivonen wrote:
On Tue, Mar 20, 2018 at 12:44 PM, Henri Sivonen wrote:
On Tue, Mar 20, 2018 at 11:12 AM, Henri Sivonen wrote:
OK. I'll leave the UTF-16 case unchanged and will make the minimal
changes on the UTF-8 side to retain the existing outward behavior
witho
On 2/6/18 6:27 PM, Tom Ritter wrote:
But when it comes to the header case mismatch issue, we could automate this.
Would it be possible for us to write some code to automatically detect these
case
discrepancies and automatically land corrections? Where would be the right place
for something like
On 1/16/18 2:59 PM, smaug wrote:
On 01/16/2018 11:41 PM, Mike Hommey wrote:
On Tue, Jan 16, 2018 at 10:02:12AM -0800, Ralph Giles wrote:
On Tue, Jan 16, 2018 at 7:51 AM, Jean-Yves Avenard
wrote:
But I would be interested in knowing how long that same Lenovo P710
takes
to compile *today*…
On 1/17/18 7:57 AM, Chris Hutten-Czapski wrote:
Hello,
Use Counters[0] as reported by the Telemetry Aggregator (via the HTTPS
API, and the aggregates dashboards on telemetry.mozilla.org) have been
over-reporting usage since bug 1204994[1] (about the middle of September,
2015). They are now fi
On 01/12/2018 11:48 AM, Kartikaya Gupta wrote:
On Fri, Jan 12, 2018 at 2:03 PM, Nicholas Alexander
wrote:
Does SF index non-trunk trees? I can't find a way to search
mozilla-{release,beta} right now. Please correct me if it does?
It does not.
I don't know too much about searchfox and dxr arc
On 1/11/18 1:44 AM, Jon Coppeard wrote:
Just a heads up: JS module scripts (
On 11/29/2017 08:35 AM, Mark Côté wrote:
I posted an update on Phabricator and Lando to my blog a couple weeks ago, but
I figured I should share it here too:
https://mrcote.info/blog/2017/11/17/phabricator-and-lando-november-update/
There are two important points:
1. Our Phabricator instance
Not necessarily relevant to this specific discussion, but I'm on a
Lenovo P50 running Linux, and wanted to offer up my setup as a
datapoint. (It's not quite either a recommendation or a word of warning.
A combination.)
I use Linux (Fedora 25) as the host OS, with two external monitors plus
th
On 10/26/17 8:22 PM, Kyle Machulis wrote:
This addition also creates the new [NeedsWindowsUndef] extended attribute,
as some WebIDL constant names conflict with windows.h macros, and undef'ing
them in the binding generation is easier than tracking down include order
issues.
Gecko seems to handl
On 10/18/17 10:28 AM, Boris Zbarsky wrote:
On 10/18/17 11:54 AM, David Teller wrote:
Mmmh... I was looking at setPendingException at
http://searchfox.org/mozilla-central/source/js/src/jscntxtinlines.h#435
That will allow you to hook all exceptions, sure, including ones
caught by try/catch.
On 9/16/17 6:43 AM, Eric Rescorla wrote:
On Fri, Sep 15, 2017 at 9:25 PM, Gregory Szorc wrote:
I'd prefer to take a data-driven approach to answering the question of "do
we need to support vanilla Git." I wish I had local developer metrics or
results from a recent developer survey to feed int
On 9/15/17 6:58 PM, Boris Zbarsky wrote:
On 9/15/17 6:30 PM, Gregory Szorc wrote:
we'd like to require the use of `mach try` for Try
submissions.
So just to be clear, instead of being able to "hg push -f try" will
one now need to do "./mach try syntax ." and put in the actual
syntax stri
On 9/12/17 7:02 AM, James Graham wrote:
On 12/09/17 14:55, Andrew Halberstadt wrote:
On Mon, Sep 11, 2017 at 10:33 PM Robert O'Callahan
wrote:
On Tue, Sep 12, 2017 at 11:38 AM, Andrew Halberstadt <
ahalberst...@mozilla.com> wrote:
I don't think so, that data already exists and is query-abl
On 07/26/2017 10:45 PM, Andrew Swan wrote:
On Wed, Jul 26, 2017 at 4:27 PM, Steve Fink <mailto:sf...@mozilla.com>> wrote:
This thread worries me greatly. Somebody tell me we have a plan
and policy around this already. Please?
We might, but I'm not sure what "thi
This thread worries me greatly. Somebody tell me we have a plan and
policy around this already. Please?
We're taking the regrettable but necessary step of killing off legacy
style extension "APIs"[1]. Necessary because e10s and the basic
impossibility of maintaining security, stability, perfor
On 07/24/2017 05:08 PM, Enrico Weigelt, metux IT consult wrote:
On 24.07.2017 21:03, Ralph Giles wrote:
I suspect this will be painful to maintain. We used to have a lot of
#ifdefs for media playback support but they weren't tested and were
usually broken, so we removed them.
Well, I'm just r
On 07/24/2017 04:03 PM, Enrico Weigelt, metux IT consult wrote:
On 24.07.2017 21:29, Steve Fink wrote:
My guess is that the compilers/linkers don't really handle heavy C++
template usage very well, and end up generating and then eliminating
massive number of duplicate template instantia
On 07/24/2017 02:13 PM, Joshua Cranmer 🐧 wrote:
On 7/24/2017 3:25 PM, Enrico Weigelt, metux IT consult wrote:
Not sure, whether an 4core i7 w/ 8GB RAM already counts as "old", but
it's really slow on my box. I've got the impression there's stil a lot
of room for optimizations. For example, I wo
On 06/21/2017 09:56 AM, Chris Peterson wrote:
On 6/21/17 8:06 AM, Boris Zbarsky wrote:
On 6/21/17 10:44 AM, Ehsan Akhgari wrote:
It seems like that we have an answer now in the bug!
https://bugzilla.mozilla.org/show_bug.cgi?id=1338651#c129
Just for clarity, so people don't have to read the wh
On 06/14/2017 10:35 AM, Andrew Swan wrote:
On Wed, Jun 14, 2017 at 10:07 AM, Nathan Froyd <mailto:nfr...@mozilla.com>> wrote:
On Wed, Jun 14, 2017 at 12:54 PM, Steve Fink mailto:sf...@mozilla.com>> wrote:
> Whoa. Experiments aren't tested in automation?
ox 55 for a restricted set
of users *only*. Basically, Test Pilot. When that team proposes
pushing out an experiment to release, the usual release process for
that team will take place.
There is no need to think about interface compatibility in the future
with external clients.
On 14 June 2017 at 1
On 06/14/2017 09:23 AM, Andrew Swan wrote:
I don't think this will be a big deal. Note that users will also be able
to run legacy addons (which can access xpcom) in Nightly with a preference
flipped. We've tried to be clear in communication to extension developers
that once 57 comes around, we
But 4 is bigger than 3, and much bigger than 0.9, so it must be way
better, right? ;-)
For the record, I have no reason to object to this plan, and
conceptually it seems like allocators always have to tune for something.
If mozjemalloc is at this time tuned to our workload, it seems very
plau
On 04/17/2017 08:11 PM, Nicholas Nethercote wrote:
On Tue, Apr 18, 2017 at 11:34 AM, Ben Kelly wrote:
I don't object to people writing longer commit messages, but that
information needs to be in the bug. Our tools today (splinter and
mozreview) don't do that automatically AFAIK. I think ther
On 03/17/2017 12:40 PM, Ted Mielczarek wrote:
On Fri, Mar 17, 2017, at 03:16 PM, Ben Kelly wrote:
For the 1:38 between Unified_cpp_js_src9.cpp and Interpreter.cpp only
a single cl.exe process is running. I guess thats closer to 8% of the
total build time. Still seems very weird to me.
Yeah,
On 03/13/2017 06:17 AM, Nathan Froyd wrote:
We do not. Bug 1299187 is related to such work, but that bug only
covers unexporting symbols that 3rd party software would access. bz
has filed a few bugs for removing nsIDOM* methods that only existed
due to 3rd party compat concerns, but I don't thi
On 03/08/2017 06:21 AM, Ehsan Akhgari wrote:
On 2017-03-07 2:49 PM, Eric Rahm wrote:
I often wonder if unified builds are making things slower for folks who use
ccache (I assume one file changing would mean a rebuild for the entire
unified chunk), I'm not sure if there's a solution to that but i
On 03/07/2017 11:34 AM, Joel Maher wrote:
Good suggestion here- I have seen so many cases where a simple
fix/disabled/unknown/needswork just do not describe it. Let me work on a
few new tags given that we have 248 bugs to date.
I am thinking maybe [stockwell turnedoff] - where the job is turned
On 03/07/2017 11:10 AM, Boris Zbarsky wrote:
On 3/7/17 2:05 PM, Mike Conley wrote:
FWIW, the MOZ_MAKE_FLAGS bit can probably be removed, as I believe mach
will just choose the optimal number based on examining your processor
cores.
Except mach's definition of "optimal" is "maybe optimize for
Is there a mechanism in place to detect when disabled intermittent tests
have been fixed?
eg, every so often you could rerun disabled tests individually a bunch
of times. Or if you can distinguish which tests are failing, run them
all a bunch of times and pick apart the wreckage to see which o
On 02/06/2017 08:19 AM, Mike Hoye wrote:
On 2017-02-03 2:01 PM, Steve Fink wrote:
Typo/whitespace - No bug is fine, but if it is associated with a
recent landing of some bug, then you should use that bug number
anyway. Makes uplifts cleaner.
Whitespace errors seem like a wierd thing for an
On 02/03/2017 09:29 AM, Gijs Kruitbosch wrote:
On 03/02/2017 15:11, Ryan VanderMeulen wrote:
A friendly reminder that per the MDN commit rules, the use of "No
bug" in the commit message is to be used sparingly - in general for
minor things like whitespace changes/comment fixes/etc where
tracea
On 12/19/2016 06:21 PM, Edmund Wong wrote:
Eric Rescorla wrote:
I'm also concerned that this spec does not seem to take into account
multipath or multihoming, both of which seem relevant here. Say that I have
a device with both a cellular and WiFi link and I attempt to use both of
them in some f
On 12/20/2016 06:20 PM, Edmund Wong wrote:
Richard Barnes wrote:
Broadly speaking, this plan would entail limiting new features to secure
contexts, followed by gradually removing legacy features from insecure
contexts. Having an overall program for HTTP deprecation makes a clear
statement to
On 08/26/2016 08:16 PM, Gregory Szorc wrote:
On Aug 26, 2016, at 19:54, Kan-Ru Chen wrote:
Hello,
In Bug 1297276 I landed a patch to rename mozilla/unused.h to
mozilla/Unused.h to make it more consistent with our other MFBT headers.
Normally rename a header shouldn't cause too much trouble,
On 07/14/2016 05:36 PM, ajo...@mozilla.com wrote:
On Friday, 15 July 2016 00:16:07 UTC+8, Georg Fritzsche wrote:
This gives an overview of the current incoming Telemetry for Linux (from a
1% sample of our data, "canonical" is the Ubuntu distribution):
https://sql.telemetry.mozilla.org/queries/6
Are either mxr or dxr really the right thing for canonical links to our
source code? As long as we're updating links, through one means or
another, temporarily or permanently, couldn't we come up with a set of
urls that would be better in the long term? One that clearly states the
purpose of a
I work remotely, normally from my laptop, and I have a single (fairly
slow) desktop usable as a compile server. (Which I normally leave off,
but when I'm doing a lot of compiling I'll turn it on. It's old and
power-hungry.)
I used distcc for a long time, but more recently have switched to icec
On 07/05/2016 01:33 AM, Julian Hector wrote:
If you encounter a crash that may be due to seccomp, please file a bug in
bugzilla and block Bug 1280415, we use it to track issues experienced on
nightly.
What would such a crash look like? Do they boil down to some system call
returning EPERM?
_
On 05/25/2016 06:09 AM, Eric Rescorla wrote:
Under "Ways to prevent" you suggest
"Ways to prevent (by making them impossible)" and rewriting in JS or Rust,
using smart pointers, etc.
This may prevent crashes in the narrow sense that it prevents SEGVs, etc.
but it does not make runtime errors tha
On 05/10/2016 01:05 PM, Jack Moffitt wrote:
We have the Chrome popularity data, and we have the Edge team's data
which covers the CSS spectrum quite well. I think it would be far more
useful to start covering the DOM API spectrum.
For example, it's pretty clear from existing data sources which C
It makes me nervous to try to make the overflow behavior the same across
engines, because it could end up restricting implementation choices. But
making things roughly the same without trying to make them too much the
same seems reasonable. And it does sound like there are situations where
we j
On 04/18/2016 07:20 AM, Lawrence Mandel wrote:
On Mon, Apr 18, 2016 at 9:04 AM, Henri Sivonen wrote:
XP has now gone for two years without security patches from Microsoft.
Additionally, as of its latest release, Chrome no longer supports XP.
When 46 ships, it would be a great time to make AUS
That's a very good point about keeping the treeherder page open eating
resources. I guess I've found that (1) my personal try push page takes
much, much longer to get overloaded than eg the inbound page (or worse,
the *full* try page); and (2) Firefox is so flaky on me for other
reasons that I
On 04/15/2016 05:11 PM, Xidorn Quan wrote:
On Sat, Apr 16, 2016 at 1:47 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:
I'm sure most of you have experienced the pain of long backlogs on Try
(Windows in particular). While we'd all love to have larger pools of test
machines (and our Op
See bug 593096. (Hah! I anticipated you guys by almost 700,000 bugs!)
It's currently WONTFIX, but there's some relevant discussion in there.
On 04/15/2016 12:46 PM, Mike Connor wrote:
If this is a serious problem, and I can easily believe that it is, have we
considered having a default behaviou
On 04/14/2016 06:21 AM, Philip Chee wrote:
On 12/04/2016 19:27, Henri Sivonen wrote:
My understanding is that
https://git.merproject.org/mer-core/qtmozembed/ still uses it. As we
are figuring out how to be more embeddable (see
https://medium.com/@david_bryant/embed-everything-9aeff6911da0 ), it
On 04/08/2016 09:13 AM, Andreas Farre wrote:
Looking for someone emacs savvy to help me with running mach --debug as a
command for M-x gdb. Currently there is an issue with mach logging a bit to
much which screws up the GDB/MI communication with emacs. Has anyone
already some solution for this? O
On 04/04/2016 10:33 AM, Ted Mielczarek wrote:
On Mon, Apr 4, 2016, at 12:46 PM, Steve Fink wrote:
I should clarify that by "non-mq", I really mean using mutable-history
aka evolve. And yes, my workflow does depend on some extensions,
including some local stuff that I haven't cl
On 04/03/2016 06:09 PM, L. David Baron wrote:
On Saturday 2016-04-02 18:51 -0300, Eric Rescorla wrote:
1. I write a bunch of code, committing along the way, so I have a lot of
commits named "Checkpoint" and "Fix bug" and the like.
2. When it works, I push the code up to the review system for rev
On 04/01/2016 08:32 AM, Gijs Kruitbosch wrote:
On 01/04/2016 16:16, Andrew McCreight wrote:
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 Playba
On 03/23/2016 02:22 PM, Gregory Szorc wrote:
Bug 1254873 changed the default behavior of configure to not build the JS
shell by default for non-standalone JS builds. The reasons are outlined in
bug 1251324. tl;dr compiling the JS shell takes a non-significant amount of
time for a feature that we
On 03/03/2016 09:59 AM, Gregory Szorc wrote:
On Thu, Mar 3, 2016 at 8:09 AM, Erik Rose wrote:
An additional bonus is that our ability to build with clang would break
less often. That's been the cause of more than a few scuttled DXR indexing
jobs.
We can and should have both Clang and GCC bui
On 01/29/2016 08:37 AM, Mike Conley wrote:
Since making the review requester feel crappy is not generally
considered good, most review requestees don't push back on MozReview
requests, even if they find it very frustrating to work with. I think
this dynamic is at the heart of a lot of the angst
On 01/26/2016 07:49 PM, Karl Tomlinson wrote:
Boris Zbarsky writes:
On 1/23/16 9:48 PM, Mike Hommey wrote:
Note that if /other/ changes from other bugs have happened to the same
files between the last reviewed iteration and the rebase before landing,
the interdiff will show them without any ki
On 01/25/2016 01:58 PM, Mike Hommey wrote:
On Mon, Jan 25, 2016 at 11:23:59AM -0800, Steve Fink wrote:
- will it be possible to still be using hg patch queues?
A valid question, though I'd not that the mq-less workflow is actually
pretty good these days. mq is still easier/nicer for
:58 PM UTC-8, nhi...@mozilla.com wrote:
I think the QC gonk layer had required 4.7 to lunch.
As far as I know you would have had to use the emulator from the get go if you
wanted to test the ril? The ril is in the Gonk layer as far as I know still
and the Gonk layer isn't in the mulet nor desk
Heh. Your list of UI complaints is very similar to mine. Some comments:
On 01/25/2016 04:26 AM, Honza Bambas wrote:
Writing both as a patch author and a reviewer as well.
- as a patch author I want a full control on when the patch actually
lands (dependencies, any other timing reasons, that o
On 01/25/2016 09:40 AM, Fabrice Desré wrote:
On 01/25/2016 09:30 AM, Ehsan Akhgari wrote:
For example, for a long time b2g partners held back our minimum
supported gcc. Now that there are no such partner requirements, perhaps
we can consider bumping up the minimum to gcc 4.8? (bug 1175546)
W
This was startling to me at first, but on further reflection, I'd like
to caution against reacting for the wrong reasons.
One driver for our current workflows is that the patch attached to
bugzilla is rarely what actually landed. With things that go through
mozreview, that need no longer be th
elated work. To me at least, that still
feels like more of the "let's throw a few smart people at the systemic
problem" approach, though. I could be wrong. Maybe we're close enough to
being able to recognize failures and direct them to the appropriate
people, who will t
On 12/29/2015 11:49 AM, Bobby Holley wrote:
On Tue, Dec 29, 2015 at 11:41 AM, Steve Fink <mailto:sf...@mozilla.com>> wrote:
On 12/22/2015 10:06 AM, L. David Baron wrote:
But I don't think having mozilla-inbound/mozilla-central be closed
more than it alrea
On 12/22/2015 10:06 AM, L. David Baron wrote:
On Tuesday 2015-12-22 11:49 -0500, Ehsan Akhgari wrote:
On 2015-12-22 11:18 AM, Kartikaya Gupta wrote:
On Mon, Dec 21, 2015 at 3:11 PM, L. David Baron wrote:
I agree it's definitely gone up recently, and agree that it causes a
lot of wasted time.
On 10/26/2015 04:01 PM, Joshua Cranmer 🐧 wrote:
On 10/26/2015 4:16 PM, Bobby Holley wrote:
Question: Would we actually need sparse checkouts? What if c-c was
just a branch in the repo with extra stuff, which periodically took
merges from m-c?
That seems like a simple and tempting idea. Ju
On 10/23/2015 10:22 AM, Benjamin Smedberg wrote:
I support going back to a giant monolithic repository if we can
cleanly delineate the code for various projects.
We know that the searchability and readability of our code is a major
barrier to some kinds of participation. We should continue to
On 10/18/2015 10:17 PM, Bobby Holley wrote:
On Sun, Oct 18, 2015 at 8:37 PM, Boris Zbarsky wrote:
On 10/18/15 7:14 PM, Nicholas Nethercote wrote:
Eventually |mach build| should just do the right
thing, no matter what files you've touched...
The problem is that definitions of "right thing"
It seems like a rather specific requirement. Also, I don't know how well
adding requirements to tier 1 jobs has worked in practice for forcing
change. There are requirements around the allowable amount of
intermittent orange, too, aren't there? And I can't say I've noticed
people jumping up to
I agree. While it is certainly true that prioritizing work based on how
many noisy people are campaigning for it is not a good idea, I reject
the notion that the only useful goal here is to prevent bugspam, as that
implies that user input is worthless.
"me too"/+1 comments on bugs are clearly
On 05/01/2015 01:50 PM, oli...@omattos.com wrote:
When plans like this aren't rolled out across all browsers together, users inevitably
come across a broken site and say "Firefox works with this site, but Safari gives a
warning. Safari must be broken". Better security is punished.
Having thi
On 05/05/2015 12:42 AM, Nicholas Nethercote wrote:
On Mon, May 4, 2015 at 11:53 PM, Leman Bennett (Omega X)
wrote:
I heard that there was rumor of a plan to limit process count spawn to
per-domain. But I've not seen offhand of a bug filed for it or anything else
that relates to achieving more t
Just thinking, but what if each profile remembered what channel it was
meant for? When using a profile in a different channel, you would have
an option to create a backup of the profile. If you were going forward,
you would get a simple notification that your profile's channel was
being advance
Is there any place in the UI to improve this via messaging? For example,
https://site.com/ => "Would you like to share your camera with
site.com?", but http://site.com/ => "Would you like to permanently share
your camera with any site claiming to be site.com? *Note: Firefox cannot
verify this c
On 01/15/2015 04:52 PM, Ehsan Akhgari wrote:
> On 2015-01-15 7:30 PM, Steve Fink wrote:
>> On 01/15/2015 11:21 AM, Ehsan Akhgari wrote:
>>> On 2015-01-14 8:37 PM, Steve Fink wrote:
>>>> On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
>>>>> From now
On 01/15/2015 11:21 AM, Ehsan Akhgari wrote:
> On 2015-01-14 8:37 PM, Steve Fink wrote:
>> On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
>>> From now on, the only supported build mode is unified compilation. I
>>> am planning to follow-up with removing support fo
On 01/15/2015 09:39 AM, Sylvestre Ledru wrote:
> On 15/01/2015 16:56, ISHIKAWA,chiaki wrote:
>> On 2015/01/15 10:37, Steve Fink wrote:
>>> On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
>>>> From now on, the only supported build mode is unified compilation. I
>
On 01/15/2015 09:31 AM, Bobby Holley wrote:
> On Wed, Jan 14, 2015 at 5:37 PM, Steve Fink <mailto:sf...@mozilla.com>> wrote:
>
> On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
> > From now on, the only supported build mode is unified
> compilation. I
>
On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
> From now on, the only supported build mode is unified compilation. I
> am planning to follow-up with removing support for the
> --disable-unified-compilation configure option altogether in bug 1121000.
I commented in the bug, but I guess this is prob
On 12/20/2014 10:11 AM, Martin Thomson wrote:
> How does this relate to "use strict"?
>
It doesn't. It's an unfortunate name collision. Strict warnings came
first, and in retrospect should have been called extra warnings or lint
warnings or something. But when there was no such thing as "use stric
On 12/08/2014 01:35 PM, Gijs Kruitbosch wrote:
> On 07/12/2014 05:11, Philip Chee wrote:
>
>>> (fwiw, *I* have no idea what "beware of leopard" means)
>>
>> That illustrates my point exactly! As in replacing "Automatic" with
>> "Beware of leopard" makes no difference to the (lack of) clarity.
>
> I
1 - 100 of 151 matches
Mail list logo
