Re: Please don't abuse "No bug" in commit messages

[Mike Hoye]

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 engineer to be working 
on?. Code cleanup bugs are how a lot of people get started, and could 
also have automatic formatting. Employees pushing whitespace around 
seems like a distant third-best.


While I also don't want people to suffer from unnecessary process 
overhead, I also want small-change bugs to be discoverable by people 
trying to start contributing. I'm not sure where that line is, but 
changes without bugs means nobody else could have helped make those changes.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The future of commit access policy for core Firefox

[Mike Hoye]

On 2017-03-14 7:10 PM, Jean-Yves Avenard wrote:

/me just loves when a new set of “rules” are put in place to prevent a problem 
that has never existed so far and will be a hindrance to everyone in the future.


Two dozen or so of our most veteran engineers are deeply involved in 
this discussion. Their time and attention are extraordinarily valuable, 
and there is no question about their commitment to Mozilla's success. 
And yet: here they are, working through the details.


On top of everything else that's been said here, maybe take a moment to 
reflect on that.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: windows build anti-virus exclusion list?

[Mike Hoye]

On 2017-03-17 12:06 AM, Ben Kelly wrote:
On Fri, Mar 17, 2017 at 12:05 AM, Ben Kelly > wrote:


On Thu, Mar 16, 2017 at 11:40 PM, Michael Hoye mailto:mh...@mozilla.com>> wrote:

Depending on your AV, if you don't exempt mozilla-central some
of our tests will get quarantined and you won't be able to
build at all.


I guess I was hoping someone familiar with our build might know
the answer. :-)


Sorry.  I think I replied to the wrong person here.


Hah! I thought "yeah, harsh but fair."

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Better download security through browsers

[Mike Hoye]

My 2006 proposal didn't get any traction either.

https://lists.w3.org/Archives/Public/public-whatwg-archive/2006Jan/0270.html

FWIW I still think it'd be a good idea with the right UI.

- mhoye

On 2017-03-24 1:16 PM, Dave Townsend wrote:

I remember that Gerv was interested in a similar idea many years ago, you
might want to see if he went anywhere with it.

https://blog.gerv.net/2005/03/link_fingerprin_1/


On Fri, Mar 24, 2017 at 10:12 AM, Gregory Szorc  wrote:


I recently reinstalled Windows 10 on one of my machines. This involved
visiting various web sites and downloading lots of software.

It is pretty common for software publishers to publish hashes or
cryptographic signatures of software so the downloaded software can be
verified. (Often times the download is performed through a CDN, mirroring
network, etc and you may not have full trust in the server operator.)

Unless you know how to practice safe security, you probably don't bother
verifying downloaded files match the signatures authors have provided.
Furthermore, many sites redundantly write documentation for how to verify
the integrity of downloads. This feels sub-optimal.

This got me thinking: why doesn't the user agent get involved to help
provide better download security? What my (not a web standard spec author)
brain came up with is standardized metadata in the HTML for the download
link (probably an ) that defines file integrity information. When the
user agent downloads that file, it automatically verifies file integrity
and fails the download or pops up a big warning box, etc or things don't
check out. In other words, this mechanism would extend the trust anchor in
the source web site (likely via a trusted x509 cert) to file downloads.
This would provide additional security over (optional) x509 cert validation
of the download server alone. Having the integrity metadata baked into the
origin site is important: you can't trust the HTTP response from the
download server because it may be from an untrusted server.

Having such a feature would also improve the web experience. How many times
have you downloaded a corrupted file? Advanced user agents (like browsers)
could keep telemetry of how often downloads fail integrity. This could be
used to identify buggy proxies, malicious ISPs rewriting content, etc.

I was curious if this enhancement to the web platform has ever been
considered and/or if it is something Mozilla would consider pushing.

gps
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Better download security through browsers

[Mike Hoye]

Love it. How do we make it happen?

- mhoye

On 2017-03-24 1:30 PM, Tom Ritter wrote:

It seems like SubResource Integrity could be extended to do this...
It's specifically for the use case: where you kinda trust your CDN,
but you want to be completely sure.

-tom

On Fri, Mar 24, 2017 at 12:24 PM, Mike Hoye  wrote:

My 2006 proposal didn't get any traction either.

https://lists.w3.org/Archives/Public/public-whatwg-archive/2006Jan/0270.html

FWIW I still think it'd be a good idea with the right UI.

- mhoye


On 2017-03-24 1:16 PM, Dave Townsend wrote:

I remember that Gerv was interested in a similar idea many years ago, you
might want to see if he went anywhere with it.

https://blog.gerv.net/2005/03/link_fingerprin_1/


On Fri, Mar 24, 2017 at 10:12 AM, Gregory Szorc  wrote:


I recently reinstalled Windows 10 on one of my machines. This involved
visiting various web sites and downloading lots of software.

It is pretty common for software publishers to publish hashes or
cryptographic signatures of software so the downloaded software can be
verified. (Often times the download is performed through a CDN, mirroring
network, etc and you may not have full trust in the server operator.)

Unless you know how to practice safe security, you probably don't bother
verifying downloaded files match the signatures authors have provided.
Furthermore, many sites redundantly write documentation for how to verify
the integrity of downloads. This feels sub-optimal.

This got me thinking: why doesn't the user agent get involved to help
provide better download security? What my (not a web standard spec
author)
brain came up with is standardized metadata in the HTML for the download
link (probably an ) that defines file integrity information. When the
user agent downloads that file, it automatically verifies file integrity
and fails the download or pops up a big warning box, etc or things don't
check out. In other words, this mechanism would extend the trust anchor
in
the source web site (likely via a trusted x509 cert) to file downloads.
This would provide additional security over (optional) x509 cert
validation
of the download server alone. Having the integrity metadata baked into
the
origin site is important: you can't trust the HTTP response from the
download server because it may be from an untrusted server.

Having such a feature would also improve the web experience. How many
times
have you downloaded a corrupted file? Advanced user agents (like
browsers)
could keep telemetry of how often downloads fail integrity. This could be
used to identify buggy proxies, malicious ISPs rewriting content, etc.

I was curious if this enhancement to the web platform has ever been
considered and/or if it is something Mozilla would consider pushing.

gps
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Phabricator Update, July 2017

[Mike Hoye]

On 7/16/17 11:10 PM, Edmund Wong wrote:

Joe Hildebrand wrote:

I'm responding at the top of the thread here so that I'm not singling out any 
particular response.

We didn't make clear in this process how much work Mark and his team did ahead 
of the decision to gather feedback from senior engineers on both Selena and my 
teams, and how deeply committed the directors have been in their support of 
this change.

Really?  So?  What exactly is your point?

This sarcasm is unwarranted.

Given that we've been talking about this stuff for years now, I think 
it's very clear that we haven't come to this point by "somebody at the 
top issuing an edict that they want something modern"; the decision to 
commit to Phabricator was ultimately announced on May 11th, and that 
decision wasn't made unilaterally or lightly.


We've been discussing how to improve our tooling and processes in open 
forums for years now, most frequently on dev-platform. Despite that, 
it's true that a lot of the major influences of this decision have been 
mostly invisible to people who aren't involved in the day to day work on 
infrastructure and tooling, in the way that icebergs are mostly invisible.


Some of the things that haven't made it into this thread that have 
influenced this decision include:


- a real and pressing requirement to update our commit access policies 
and practices, and backstop them with reliable tooling (a discussion you 
participated in, as I recall),
- the significant engineering burdens (including opportunity cost and 
bus-factor risk) of being the sole owner/user of a major piece of 
infrastructure software that's not our core product, and
- the much more pernicious set of hidden costs we incur from _failing_ 
to standardize on certain tools and processes.


It's a very serious drag on product development and contributor 
participation if everyone - paid senior engineers and new contributors 
alike -  needs to use _this_ tool and process and coding style (and and 
and) to participate in one part of the project, and _that_ etc. etc. to 
participate in another. Or, sometimes, even other corners of the same 
codebase.


Each of those on their own is a huge deal, probably big enough to 
warrant a major change in our tooling and processes. And it's true that 
we haven't done a great job of explicitly spelling out what a big deal 
they are, and how much they've informed our decision-making. But while 
we support - and will always support - user choice in our products, 
there aren't enough engineering hours in a year for us to support a 
bunch of different ways of shipping, securing, measuring and improving 
the tools and processes that provide those choices _to_ our users.


So, yes, we could have done a better job of communicating here and 
making our process more transparent, but I'm very confident that this 
decision will make life a lot better for Mozilla's casual contributors 
and broader community as much as for Mozilla's full-time engineers. If 
you'd like to dig into the details of "why" I'd be happy to do so. And 
if we can do that without unnecessary snark, all the better.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Mike Hoye]

On 2017-07-19 3:58 AM, Chris Peterson wrote:


On 2017-07-19 12:01 AM, Mike Hommey wrote:

What's the plan for eligible people that still want to keep 32-bit
Firefox? 
Outside of our QA team (or others orgs, I guess?) do we have a set of 
use cases that would motivate people to flip that switch?




Are they going to have to stop auto upgrades, which would get
them automatically on 64-bits and upgrade manually? This is especially
going to be a problem for users with less than 2GB RAM that do still
want 32-bit Firefox if we decide against the minimum memory requirement.


We have two options in mind: 

Is ESR on the radar while you're planning this, or is it unrelated?

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: sensor APIs

[Mike Hoye]

I have a sense that as AR gets richer and more nuanced that ambient 
light and proximity sensing will become important as well, even if we're 
not there yet.


- mhoye

On 2017-07-24 10:39 AM, Blair MacIntyre wrote:

I was just about to say the same thing.  This API is essential for our AR work; 
 the fact that Firefox is different than other browsers is problematic, but 
there are javascript libraries that help with it.  Getting rid of it would be 
really bad.


On Jul 24, 2017, at 9:57 AM, Ben Kelly  wrote:

On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren  wrote:


* Device orientation


Isn't this one required to build a decent web experience on mobile for some
sites?  It seems pretty common on mobile to adjust the UX based on whether
the device is in portrait/landscape orientation.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Announcing MozillaBuild 3.0 Release

[Mike Hoye]

On 2017-07-22 3:13 AM, Frank-Rainer Grahl wrote:
Personally I find this a bad idea. Windows 7 and 8.1 are still 
supported till 2020 and 2023. As long as the compilers are supported 
too on them these should also be fully supported as a build environment. 
Unfortunately we have to build _for_ a number of our supported operating 
systems without being able to build _on_ those operating systems. That's 
been true for some time now; while we still support 32-bit systems, for 
example, you can't build Firefox on 32-bit systems at all due to memory 
constraints, and the new MozillaBuild system is 64-bit only due to a 
variety of dependencies.


This means some people on older hardware or OSes aren't able build 
Firefox, that's true, but it doesn't mean they have no way to contribute 
to Firefox, and restricting ourselves to only shipping a product that we 
can build directly on those older systems means giving every single 
person who relies on those systems a crap experience and a substandard 
product.


It'd be nice in some abstract sense to be able to bootstrap a Firefox 
executable on every system we support, but the tradeoffs we'd need to 
accept to do that (support costs, development velocity, actual 
as-delivered product quality and a lot more) are _so_ egregiously bad 
for everyone involved that there's no reasonable, much less responsible, 
way we can invest any time or effort making that happen.




- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS/2 still supported ?

[Mike Hoye]

On 2017-07-24 8:27 PM, Enrico Weigelt, metux IT consult wrote:

Hi folks,


I see lots of #ifdef XP_OS2 ... is OS/2 still supported at all ? 

Our list of supported platforms is here:

https://developer.mozilla.org/en/docs/Supported_build_configurations

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I need to give my 2–coins–worth on this topic, please. (Re: Can we make a plan to retire Universal Mac builds?)

[Mike Hoye]

On 2015-08-15 3:02 PM, Cameron Kaiser wrote:

On 8/12/15 3:32 PM, Mike Hommey wrote:
> Relatedly, why does Tenfourfox use a different branding?

Because I didn't want to get into the whole Ice* thing again.


I have nothing to add to this except to say that this is a pure and 
noble goal, and I salute you.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Decreasing quality?

[Mike Hoye]

On 2015-08-20 2:35 PM, Dirkjan Ochtman wrote:

I'm not talking about any specific issues, I was just wondering if
others were seeing a trend.
For what it's worth, living on Nightly + e10s + a multiscreen setup has 
been pretty hard on the soul for a couple of months now, but I don't 
think that's a sign of decreasing attention to quality or detail. That's 
just the price of being in the crumple zone of a big, ambitious 
architectural change, better we pay it on Nightly than release.



- mhoye

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Prioritizing tests based on file changes

[Mike Hoye]

On 2015-09-03 4:24 PM, Christopher Manchester wrote:

Work is ongoing on an approach to select/prioritize tests based on the
files that a push changes.

https://youtu.be/IUZEtVbJT5c?t=20


- mhoye

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: TIFU by using Math.random()

[Mike Hoye]

On 2015-11-25 9:33 AM, Frederik Braun wrote:

On 25.11.2015 12:42, Philip Chee wrote:



Hopefully Spidermonkey's Math.random() is better.

Phil


There have been multiple insightful responses on HN and reddit/netsec.
The short version is, that Math.random() isn't providing statistically
good randomness, because JS benchmarks use it. So it has been optimized
for performance in most browsers.
That article's key takeaway is that the word "performance" doesn't 
really mean anything absent a bunch of context-specific qualifiers, and 
you're going to get bitten if you don't understand them. Doing the wrong 
thing really fast is not hard.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Mike Hoye]

On 2015-11-26 11:07 AM, Thomas Zimmermann wrote:


I haven't followed the overall discussion closely, but

This is not OK.

Does anyone here actually think that the team that's been busting their 
asses over this for months _doesn't_ have better information and more 
insight into this problem than what you've come up with after thinking 
about it for five minutes? That all the data they've gathered, all the 
experience and expertise they're bringing to bear on this problem are 
just sitting in a box in the corner somewhere while they daydream how 
much fun it is to write security-critical software and brush off our 
users' rights and developer community's needs?


Really?

Stillman wrote some new code and put it through a process meant to catch 
problems in old code, and it passed. That's unfortunate, but does it 
really surprise anyone that security is an evolving process? That it 
might be be full of hard tradeoffs? There is a _huge_gap_ between "new 
code can defeat old security measures" and "therefore all the old 
security measures are useless". It's an even bigger step from there to 
the implication that people working on this either haven't thought about 
it already, or just don't care.


We're bad at communications, I get that, but maybe we could all talk to 
someone on that team for ten minutes before telling them how to do their 
jobs. Ask them about their reasoning, what decisions they made and why, 
what the tradeoffs were. I have, and watching the discussion in this 
thread is like watching someone tell Jason Bourne he should tie his 
shoes and look both ways before crossing the street. It would be 
hilarious if I didn't know for a fact that it's insulting and 
demoralizing to really smart people who've worked hard and cared 
intensely about Mozilla's users and developers for a long, long time.




- mhoye



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Mike Hoye]

On 2015-11-28 2:40 PM, Eric Rescorla wrote:

How odd that your e-mail was in response to mine, then.


Thanks, super helpful, really moved the discussion forward, high five.

To Ehsan's point that "malicious code here might look like this: 
console.log("success"); [and] It's impossible to tell by looking at the 
code whether that line prints a success message on the console, or 
something entirely different, such as running calc.exe." - that's true, 
but it also looks a lot like the sort of problem antivirus vendors have 
been dealing with for a long time now. Turing completeness is a thing, 
the halting problem exists and monsters are real, sure, but that doesn't 
mean having antivirus software is a waste of time that solves no 
problems and protects nobody.


One key claim Stillman made, that  " A system that takes five minutes to 
circumvent does not “raise the bar” in any real way", is perhaps true in 
an academic sense, but not in a practical one. We know a lot more than 
we did a decade ago about the nature of malicious online actors, and one 
of the things we know for a fact is the great majority of malicious 
actors on the 'net are - precisely as Jorge asserts - lazy, and that 
minor speedbumps - sometimes as little as a couple of extra clicks - are 
an effective barrier to people who are doing whatever it is they're 
about to do because they're bored and it's easy. And that's most of them.


Any semicompetent locksmith can walk through your locked front door 
without breaking stride, but you lock it anyway because keeping out 
badly-raised teenagers is not "security theater", it's sensible, 
cost-effective risk management.


- mhoye

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

[Mike Hoye]

On 2015-12-14 4:06 PM, Justin Dolske wrote:

On 12/14/15 2:51 AM, Ted Mielczarek wrote:


[...]Obviously this isn't something we like to see, but
we shouldn't let the support of non-Tier 1 platforms guide our decision
making to that extent. Enabling Rust components in Gecko is important
work, and outweighs the value of supporting Firefox on minority
platforms.


+1. We shouldn't be doing any work to maintain Tier-3 platforms, nor 
should they hold us back from modernizing and securing the platforms 
used by the overwhelming majority of our users.


While I agree with this, giving those tier-3 platform maintainers as 
much advanced notice as possible and good-faith-if-low-touch guidance as 
to how they can keep rolling would be a fine thing.


I see a few names with no mailing addresses for a number of people on 
the supported build configurations page, so I'm going to see if I can 
find them and ask them to add their contact information.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

[Mike Hoye]

On 2016-01-04 12:31 PM, Bobby Holley wrote:
By "this sort of software" do you mean "Firefox"? Because that's what 
95% of our users experiencing this are going to do absent anything 
clever on our end. We clearly need to determine the scale of the 
problem to determine how much time it's worth investing into this. But 
I think we should assume that an affected user is a lost use in this case
Is consumer-grade home networking gear on our radar here?  Many, many 
home APs will self-generate SHA-1 certificates on their first boot after 
a reset.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

[Mike Hoye]

On 2016-01-04 12:48 PM, Eric Rescorla wrote:
On Mon, Jan 4, 2016 at 9:47 AM, Mike Hoye <mailto:mh...@mozilla.com>> wrote:


On 2016-01-04 12:31 PM, Bobby Holley wrote:

By "this sort of software" do you mean "Firefox"? Because
that's what 95% of our users experiencing this are going to do
absent anything clever on our end. We clearly need to
determine the scale of the problem to determine how much time
it's worth investing into this. But I think we should assume
that an affected user is a lost use in this case

Is consumer-grade home networking gear on our radar here? Many,
many home APs will self-generate SHA-1 certificates on their first
boot after a reset.


The certificates from those devices aren't valid in any case, because
they do not chain to a trust anchor.
I'm really asking about the user experience. If it's the same "add an 
exception and proceed" process, that's not great, but we're no worse off 
and my concerns are unfounded.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Where to put docker documentation?

[Mike Hoye]

On 2016-01-22 12:07 PM, Armen Zambrano G. wrote:

We're now running side by side Linux x64 debug test jobs inside of
docker on TaskCluster [1]

Where could I add instructions on how to run jobs running inside of
docker? (mdn? the tree? else?)
MDN please. Docker is going to going to be important for community 
participation in infrastructure, so MDN docs would be very helpful.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Mike Hoye]

On 2016-01-29 2:05 PM, Cameron Kaiser wrote:

On 1/29/16 9:43 AM, Ashley Gullen wrote:

FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
"other settings"): http://store.steampowered.com/hwsurvey


For that to be valid, one must assume that the population of Firefox 
users and Steam users are sufficiently similar. I don't think that's 
necessarily true since most Steam titles have substantially higher 
system requirements.
While that's a fair point, Microsoft turned compiling with SSE2 on by 
default in Visual Studio in 2012, and it's been basically impossible to 
buy an x86 CPU without it since...  2004 or so?


I've tapped chutten about this, and he says:

14:33 < chutten> Easy as pie. ping["environment/system/cpu/extensions"] 
contains "SSE2"

14:33 < chutten> or, rather, the inverse

... which he then explained to me means "we can get our own data in 
short order."


He says it'll be straightforward to pull in, so he's going to do that.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Mike Hoye]

On 2016-03-29 8:09 PM, Eric Rescorla wrote:


On a more substantive, less procedural note, this seems to be designed 
for a particular workflow in which there is an assumption that bugs 
are for immediate processing. However, in may cases we use bugs as 
placeholders or assemble big dependency trees of all the bugs that are 
needed to do a large complex feature.
We're definitely talking about untriaged incoming bugs here, not 
placeholder or planning bugs, though it's true that the doc doesn't call 
that out explicitly. I'll add a comment to that effect.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Introducing MOZ_ALWAYS_SUCCEEDS

[Mike Hoye]

On 2016-03-29 5:19 PM, Kyle Huey wrote:

For when you are too lazy to type MOZ_ALWAYS_TRUE(NS_SUCCEEDS(foo)).

Any chance we can get this on a t-shirt?

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Mike Hoye]

On 2016-04-01 11:32 AM, Gijs Kruitbosch wrote:



On 01/04/2016 16:16, Andrew McCreight wrote:


The drawback of indicating priorities in this way is that it is totally
opaque to anybody who is not on that particular subteam, let alone 
somebody
who is using Bugzilla for the first time to report breakage on a site 
they

use. If this was marked "backlog" or whatever instead of "P5", and there
was a link to an explanation of what "backlog" meant, then it would 
make it
much easier for people to figure out what is going on in any bug. I 
think

that is a big advantage of the proposed triaging system, even though I
think it is reasonable for anybody to be skeptical of adding even more
bells and whistles to the Bugzilla interface.



Concur. Slight (related) aside: I've seen plenty of new bugreporters 
set priority to P5 and severity to critical - clearly, the highest 
number is the highest priority, right? In other words, I don't know 
that P1 being highest-prio is necessarily obvious to everyone.


That, I suspect, is just a taste of the hidden costs of having different 
"bugzilla-dialects" across the entire organization.


Programmatically making a non-trivial assertion about the state of a 
single bug is really difficult now, so automating or dashboarding 
anything is always a per-team one-off throwaway. It's difficult to get 
aggregated information to managers, adds a bunch of friction between 
collaborating teams and increases the risk of human error.


Not to mention, it's a real barrier to participation. I'm invested in 
this because I want to make it easier for our community members to get 
involved productively.  I'm convinced that the same standard 
nomenclature that will make it easier for new, non-English-native 
participants to work in Bugzilla effectively will also make it easier 
for everyone at a manager level or higher to communicate and coordinate 
efforts.


- mhoye


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proof-of-concept firefox branch

[Mike Hoye]

On 2016-04-25 2:41 PM, a...@imgland.xyz wrote:
I am a developer who has experimented with Firefox tweaking before and 
I would be intrested in running a "proof-of-concept" branch or fork of 
Firefox with the latest features added before any sort of review to 
see how they play out in a normal browser. I would like to have 
everybody's thoughts on this before I release anything and would like 
to know the possibility of Mozilla ever endorsing this.


We've got what you might call "proof of concept" branches of Firefox 
already in our prerelease channels; if you to get a sense of what the 
latest and greatest looks like, Firefox Nightly is the place to be, and 
Developer Edition is a bit less exciting, but a lot more 
web-developer-ey, so you can pick what works for you.


Your best bet for experimenting with Firefox features is almost 
certainly via Addons, and the active and rapidly growing community 
around them. You are, of course, welcome to fork the code and do 
(almost, see the MPL) whatever you like with it. But if you want your 
experimental fork to keep pace with our own day to day development 
(which includes security improvements, so you _really do_ want to do 
that) and to be able to share your changes with other people, then 
living in Nightly or Dev Edition and experimenting via addons is the way 
to go.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reverting to VS2013 on central and aurora

[Mike Hoye]

On 2016-05-06 12:26 AM, Gregory Szorc wrote:

FWIW, the crashes we've seen so far are from incorrectly emitted movss
instructions. This instruction is part of the original SSE instruction set,
which was initially unveiled by Intel on the Pentium 3 in 1999 and later by
AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still need
Firefox to run on processors manufactured in the 90s.
Per an IRC conversation with chutten, Firefox users on CPUs that do not 
support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2). 
A third of those are on otherwise-unsupported configurations (pre-SP3 
XP, etc), this work provides continuity of support to 0.01% of our users.


- mhoye


09:59  So, to put it clearly and precisely, of the Firefox 
Population in release and beta who are reporting at least base telemetry 
collection on machines running supported configurations, only 0.01% 
cannot definitively say they have SSE.
10:00  (according to a 1% random sample as stored in the 
longitudinal dataset)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ignoring viewpoints of non-Mozilla-employees can't be the way to go for a OSS project!

[Mike Hoye]

On 2016-05-09 2:23 PM, Tobias B. Besemer wrote:

Think Mozilla should find his way back to his roots!
Would be nice, if some people think about it!
While reasonable people can disagree about policy decisions, Bugzilla 
has never been the right place to air those disagreements.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring SSE2 on all 32-bit x86 OSs

[Mike Hoye]

On 2016-05-18 7:38 AM, Tobias B. Besemer wrote:

N00b question:
Is this really a discussion if Firefox should support CPUs older then 13-15 
years ??
Right now Firefox supports users on platforms their creators have long 
abandoned - WinXP, pre-SSE2 CPUs, OSX 10.6-8, older Android. Firefox is 
the _only_ choice people on those platforms have for a safe, modern web 
browser, and ending support for them will have real consequences for 
real people.


We can't support everyone on every platform forever, obviously, and 
being the dominant browser on a set of obsolete or dying platforms isn't 
a compelling long-term investment of our resources. But it's a good bet 
that people using those systems can't easily upgrade, so ending support 
for a platform inevitably means exposing those users to unknown risks. 
So it's not a decision people who care about their users' safety and 
security should make casually, without careful deliberation and the best 
data available.


So to answer your question: Yeah, sort of. This is kind of a discussion 
about whether Firefox should support 15-year-old CPUs, but it's really 
about the costs, benefits and trade-offs involved in deploying scarce 
engineering resources in a complex environment, and how to best support 
our users and advance Mozilla's mission in that context.


For what it's worth I think our users deserve to know we take these 
questions seriously, whatever the final decisions, and I'm glad we do.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Starting to contribute (Need Help!!)

[Mike Hoye]

On 2016-05-20 4:23 PM, mistr...@iitj.ac.in wrote:

Hi everyone!
I am an undergraduate student and I want to start contributing to the Mozilla 
community. So it would be awesome if someone could tell me where to start from 
specifically and also what should I learn before starting.

Hi!

Thanks for your interest; there are a few ways you can get started.

The Contribute page here: https://www.mozilla.org/en-US/contribute/

can give you some good suggestions, and in a more question-and-answer 
format you can look at


http://whatcanidoformozilla.org/

If those don't point you in the right direction, feel free to email me 
directly and we can try to figure out what you're interested in and how 
we can find a place to put your effort that would be a good fit.


Thank you,

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How do we measure active users on a given architecture?

[Mike Hoye]

On 2016-05-25 2:04 AM, Eric Rahm wrote:

So my question is: How many of these users are actively
updating? I think this would be useful in making decisions on what support
to deprecate.
You should come to the "Accessing Data @ Mozilla" elective in London. 
It'll be a whole series of lightning talks about what data we gather at 
Mozilla, how to access it and who to go to with more questions. Should 
be a good time.


In the meantime, to that specific question: I got that information from 
Chris H-C, and I bet he could answer your followup question in no time.


Red rover, red rover, I call chutten over.

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How badly out of date is this?

[Mike Hoye]

On 2016-06-01 5:02 AM, L. David Baron wrote:


So I tend to think it's worth keeping, but with a preface that
clearly labels it as historical and no longer good practice, and
perhaps with an appendix pointing to the current practices.


Hey, Sheppy - Should we make a practice of stripping anchor links from 
historical/outdated/archived documentation? On a few occasions I've had 
links drop me into the middle of a document, skipping over the big red 
warning at the top saying "this is old, don't do any of this". I might 
be alone in this, but I suspect I'm not the only person who's lost time 
because of it.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 32-bit developer edition?

[Mike Hoye]

On 2016-06-03 8:51 AM, Ben Kelly wrote:
In any case, we're not showing a 64-bit link anywhere now. Who should 
I pester or where should I file a bug to get that fixed? 

Mozilla.org :: webdev



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MXR permanently offline, please transition to DXR

[Mike Hoye]

On 2016-06-24 6:20 AM, Philip Chee wrote:


I wonder what is necessary to set up an instance of MXR (for comm-*) on
our own server (or vps). I would guess PERL, hg, and a Linux VM.
I've got the impression that comm-* has enough rocks to push up the 
legacy-stack hill already.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: URL translation map Re: MXR permanently offline, please transition to DXR

[Mike Hoye]

On 2016-06-30 9:50 PM, Karl Dubost wrote:

Gregory,

Le 1 juil. 2016 à 09:33, Gregory Szorc  a écrit :

I want the site to publish a "URL translation map"
for URL patterns so whole URL namespaces can be bulk updated.

Interesting idea.

Probably something to explain in a wiki page somewhere on 
https://wiki.mozilla.org/ with use cases and examples how you would see it 
working.

This sounds like Apache's "Redirect" or "RedirectMatch" config options.

More powerfully, Apache's mod_rewrite can be made to return a 301 and 
redirect you to one of a series of regex-modified rewrites of the 
inbound URL.




- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: URL translation map Re: MXR permanently offline, please transition to DXR

[Mike Hoye]

On 2016-07-06 1:46 AM, Tim Guan-tin Chien wrote:
We really need to get the vanilla redirect done at least, since, 
ironically, "mxr.mozilla.org " is even 
referenced in the code base!


https://dxr.mozilla.org/mozilla-central/search?q=mxr.mozilla.org&redirect=false


Cleaning those up is a good first bug, I think. Is that one filed yet? 
If not, I'll file it directly.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: URL translation map Re: MXR permanently offline, please transition to DXR

[Mike Hoye]

On 2016-07-06 11:08 AM, Tim Guan-tin Chien wrote:
I didn't file the bug because I don't know if it make sense to rewrite 
on the source tree (instead of implementing the rewrite). Feel free to 
file. Thanks.

Bug 1284887 filed, thanks.

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rationalising Linux audio backend support

[Mike Hoye]

On 2016-07-13 10:31 PM, ajo...@mozilla.com wrote:

Our official Firefox builds on Linux support both PulseAudio and ALSA. There 
are a number of additional contributed backends that can be turned on at 
compile time, although contribution towards long-term maintenance and matching 
feature parity with the actively developed backends has been low. On Linux, we 
actively maintain the PulseAudio backend but we also approach the PulseAudio 
developers when we see issues in PulseAudio. The PulseAudio developers are 
generally good to work with.
FWIW all of Arch, Fedora, Debian (including Raspian), (U/Ku/Xu)buntu, 
Mint, OpenSUSE ship PulseAudio by default, and have for a long time. 
You've got to work pretty hard to find a desktop linux distribution that 
doesn't; even Gentoo and Android-x86 have it reliably available.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using Firefox to test the Visual C++ compiler

[Mike Hoye]

On 2016-11-16 2:29 PM, Ralph Giles wrote:



3. What Windows OS do you use for testing? Window 10, Windows 8, etc? Any other 
configuration work needed, such as disabling the antivirus/firewall?

We build on Windows 8, Windows XP (possibly actually NT 2008?) and
Windows 2012 aws images. Look for `B` jobs on the treeherder site
linked above. Once you have a copy of the source and the build
environment, no network access should be necessary.


You should disable AV checking on the source and object folders. I can 
be an unpleasant performance hit, and some AVs will quarantine some 
regression tests causing builds to fail.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Terminating xulrunner?

[Mike Hoye]

On 2016-11-28 9:32 PM, edunl...@gmail.com wrote:

My Firefox Thunderbird will not open correctly because it wants XUL Runner to 
be 45.5.0.  Can you help me?


Unfortunately, XULRunner hasn't been under active development since 
mid-2015, and was never officially supported.


I suggest downloading and reinstalling the most recent version of 
Thunderbird, available here:


https://www.mozilla.org/en-US/thunderbird/

This may resolve your issue. You can email me directly if it doesn't, 
and I'll see if I can direct you to the right people in the Thunderbird 
community.


- mhoye



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: GCC 4.9 now required to build on Linux/Android

[Mike Hoye]

On 2016-12-23 11:08 AM, Nathan Froyd wrote:

Bug 1322792 has landed on inbound, which changes configure to require
GCC 4.9 to build; our automation switched over to GCC 4.9 for our
Linux builds earlier this week.  (Android builds have been using GCC
4.9 for some time.)



I happened to be poking at the MDN docs when this came in, so I'll 
update them to reflect this.


I haven't tested our minimum hardware recommendations on Linux - 2GB 
ram, 30GB free space - recently, but I'll test them in the new year.


Anyone know offhand if it's still possible to build on a 32-bit Linux 
box? We haven't been able to build on 32-bit Windows for a while now.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Code Review Session

[Mike Hoye]

On 2013-05-27 10:54 PM, Anthony Jones wrote:

A pre-upload check would give the fastest feedback.

It would help me (and those who review my code) if there is an easy way
to check my patches from the command line before doing hg bzexport. Even
if it is only for white space. What we need is a way to specify which
file paths the standard formatting rules apply to. I just need to figure
out how to install clang-format.


The clang-format list tells me that there are near-term plans for a 
standalone "clang-tidy" utility built on clang-format that will do much 
of what we're looking for as far as basic code-cleanup goes. I'm asking 
around about what "near-term" means, and if the answer isn't good enough 
I'm going to try to add something to clang-format to give users some 
moz-style guidance as a temporary measure.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: review stop-energy (was 24hour review)

[Mike Hoye]

On 2013-07-11 2:14 PM, Jet Villegas wrote:

I may have a skewed view of things, but I personally have not had problems 
getting prompt code reviews. I also don't have a problem talking to my 
reviewers about what I'm hacking on. I'm hesitant to throw a bunch of 
technology at this problem, if it's a social issue. Code reviews are a 
conversation and more code has to come with more conversations.
For what it's worth, there's some data on the subject available (inside 
the firewall only, unfortunately) here:


https://metrics.mozilla.com/bugzilla-analysis/ReviewIntensity.html#sampleInterval=day&sampleMax=2013-07-15&sampleMin=2013-01-15&requestee=

You can drill into that data on a per-project or per-team basis, but in 
aggregate you can see that in the last six months more than two-thirds 
of reviews already happen in less than a day, and it tails off pretty 
sharply after that.


That's not to say there's not room for improvement there; the ~2200 
reviews that take two or three days, and ~1700 that take four to six, vs 
the ~12500 one-days, still seems like a lot, and I agree with Jet that 
some communication - particularly with new contributors or first-timers 
- would go a long way to relieving the stop-energy problem even if you 
can't get to the review in the next eight hours.


There's a blip at the right hand side of the graph there, but a casual 
inspection of the "over 10 days" pile seems to indicate that those are 
mostly hard problems, not neglect.


- mhoye

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: requiring build peer review for Makefile.in changes

[Mike Hoye]

On 2013-07-18 10:49 AM, Joe Drew wrote:
I am 100% in favour of this. My only request is that build peers 
implement something similar to Firefox's catch-all reviewer account, 
because suggested reviewers won't work for most build changes (the bug 
won't be filed in Core::Build Config). If I can type :build-peer 
instead of :gps, it'll even out the load.


I'll add something comparable to my reviewer-suggesting tool, making 
sure Makefile.in files are flagged as requiring special attention.


If there are other files or classes of file that require that "changes 
to files of type X must get a review by group Y" treatment, let me know.


- mhoye


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: Email individual patch authors who improve performance

[Mike Hoye]

On 2013-08-12 6:14 PM, Matt Brubeck wrote:

I've posted a patch that would change how the graph server sends email
when a performance *improvement* is detected:
https://bugzilla.mozilla.org/show_bug.cgi?id=904250


This is really great.

Can other addresses be CC'ed when this specifically (and in the future, 
other automatically-detectable improvements) are accomplished? I'd like 
to be able to automate badge-assignment stuff on Mozillians as much as 
possible, and this would be a big help.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Detection of unlabeled UTF-8

[Mike Hoye]

On 2013-08-30 11:17 AM, Adam Roach wrote:

It seems to me that there's an important balance here between (a) 
letting developers discover their configuration error and (b) allowing 
users to render misconfigured content without specialized knowledge.


For what it's worth Internet Explorer handled this (before UTF-8 and 
caring about JS performance were a thing) by guessing what encoding to 
use, comparing a letter-frequency-analysis of a page's content to a 
table of what bytes are most common in which in what encodings of 
whatever languages. It's probably not a suitable approach in modernity, 
because of performance problems and horrible-though-rare edge cases.


If whatever you'd written turned out to have an unusual letter frequency 
or (worse) when a comment added to your badly-written CMS tripped that 
switch, your previously-Korean page would suddenly and magically start 
rendering in Hebrew or something, and unless you knew something about 
character encoding in IE it was basically impossible to figure out what 
had gone wrong or why. From both the developer and user perspectives, it 
was amounted to "something went wrong because of bad magic."




- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Detection of unlabeled UTF-8

[Mike Hoye]

On 2013-08-30 3:17 PM, Adam Roach wrote:

On 8/30/13 14:11, Adam Roach wrote:
...helping the user understand why the headline they're trying to 
read renders as "Ð' Ð"оÑ?дÑfме пÑEURедложили 
оÑ,обÑEURаÑ,ÑOE "Ð?обелÑ?" Ñf Ðz(бамÑ< " rather than "? 
??? ??  "??" ? ?".


Well, *there's* a heavy dose of irony in the context of this thread. I 
wonder what rules our mailing list server applies for character set 
decimation.


When I sent that out, the question marks were a perfectly readable 
string of Cyrillic characters.


Which provides a strong object lesson in the fact that character set 
configuration is hard. If we can't get this right internally, I think 
we've lost the moral ground in saying that others should be able to, 
and tough luck if they can't.


For what it's worth, the original came through Thunderbird as a 
perfectly legitimate string of Russian at my end:



??? ?? ? , ??? ?? ??? , ??? ??  ?? ? 
 ??. ??? ??   ???, ??? ?? ??? ?? 
, ?? ??? ??  ? ??? ? ???.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Detection of unlabeled UTF-8

[Mike Hoye]

On 2013-09-05 10:10 AM, Henri Sivonen wrote:
It's worth noting that for other classes of authoring errors (except 
for errors in https deployment) we don't give the user the tools to 
remedy authoring errors.


Firefox silently remedies all kinds authoring errors.

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Recent build time improvements due to unified sources

[Mike Hoye]

On 11/28/2013, 12:14 PM, Ehsan Akhgari wrote:

Please file a bug (and CC me) with more details about where the build 
fails, how much memory the machine has, and how much memory each 
compiler invocation consumes (test with make -j1).  We can adjust the 
number of files we build in one chunk per directory, so this is easily 
fixable.  "Buy more RAM" is a terrible answer to this kind of problem.


Particularly when that's not an option at all for many current and 
prospective contributors, yeah.


Right now the build page on MDN says " More than 2 GB of RAM for recent 
Firefox builds, 4 GB or higher recommended", but it's important for our 
community to have a more granular understanding of our requirements 
there, and to make sure it stays possible - not "efficient" or 
"pleasant" or anything, just "possible at all" - to build Firefox on 
low-end machines.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Recent build time improvements due to unified sources

[Mike Hoye]

On 11/28/2013, 4:45 PM, Nicholas Nethercote wrote:
I'm pretty sure that gps was saying "if you're paid to work by 
Mozilla, get a faster machine". More generally, we're all in furious 
agreement: fast builds are good; achieving them via multiple means is 
worthwhile; those with the option of getting faster hardware should do so.


That's all true, but if we end up in a place where a box with "only" 2GB 
of RAM can't build Firefox at all that will be a serious problem, and a 
major barrier to community participation. I get that this can't be true 
for phones, sure, but "official support" for Firefox shouldn't just mean 
"you can run Firefox on this platform", it should as often as possible 
also mean "you can build Firefox on this platform."



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?

[Mike Hoye]

On 12/8/2013, 4:49 AM, Robert O'Callahan wrote:

Don't these arguments apply to desktop Firefox used at work, in an Internet
cafe, or in a library, as well?
Media is a power hog on mobile, so it's worthwhile to handle it 
differently there.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: A proposal to reduce the number of styles in Mozilla code

[Mike Hoye]

I was asked, in the previous discussion about code formatting, to 
provide some research on the subject. I'm sorry I didn't get back to 
that fast enough, but here we are.


We have a lot of data on this: Michael Hansen at Indiana University has 
done a series of eye-tracking experiments regarding code formatting 
standards and programmer efficiency and comprehension.


He's written a blog post about it here: 
http://synesthesiam.com/posts/what-makes-code-hard-to-understand.html


...and the longer publication is here: 
http://arxiv.org/pdf/1304.5257v2.pdf   - linked from 
http://arxiv.org/abs/1304.5257 if you want citation information or other 
formats.


You should read the whole thing, obviously, but a few choice 
observations include the fact that small inconsistencies in formatting 
have been unequivocally proven to cause dramatic drops in comprehension 
and productivity. Likewise, dead code or even just code that doesn't 
follow logically from the code above it.


Another observation is that experienced programmers just don't read code 
the same way novices do. Novices go word-by-word, line-by-line, and 
veterans tend to jump around scanning for keywords and code blocks; the 
kicker is that when experienced software engineers see a file or code 
block that's in an inconsistent _or just unfamiliar_ format, their 
brains kick them out of their block-analysis mode and they have to go 
back to reading line by line.


You can actually _see this happen_ with eye tracking software, is the 
amazing thing.


The implication, relevant to individual employees and community 
contributors as well as Mozilla as a fast-moving organization, is that:


- by not having a single coding standard we are making it a lot more 
expensive and error-prone for contributors and employees to move from 
one part of the project to another, and

- those costs are very real and largely hidden.

There's a long history of research - Solloway and Ehrlich as early as 
1984 is one example - that says pretty much the same thing. Experienced 
programmers have very strong, learned expectations about what a codebase 
_should_ look like, and when it does not look like that, or when they 
have to get used to a new system, productivity and comprehension drop 
sharply.


Their paper's available here: 
http://www.ics.uci.edu/~redmiles/inf233-FQ07/oldpapers/SollowayEhrlich.pdf 
- but it's pretty typically hard-on-the-eyes early IEEE stuff, a scan of 
a printout.


Coding standards are nice, and we should have them for sure, but they 
should inform the design of a formatting tool, not be a style coach. We 
should have a standard, and it should be enforced by a machine before 
any of this ever hits a human - particularly a reviewer - in the eyes. 
And from a community-engagement perspective, this matters. Every time we 
type "nit" and send a patch back instead of cleaned up and ship-ready by 
a tool is one more chance to miss an bunch of opportunities, to have 
somebody get fed up and leave and let that patch rot on the vine. It's 
one more small, annoying barrier to participation, and it'd be great if 
we could have automation in place to make it go away.



- mhoye


On 1/6/2014, 12:55 PM, Martin Thomson wrote:

I think that this is a good start, but it doesn’t go quite far enough.

Part of the problem with a policy that requires people to avoid reformatting of 
stuff they don’t touch is that it propagates formatting divergence.  Sometimes 
because it’s better to conform to the style immediately adjacent the changed, 
but more so because it prevents the use of tools that reformat entire files 
(here, I’m not talking about things like names, but more whitespace 
conventions).

For whitespace at least, I think that we need to do the following:

  1. pick a style

I really, really don’t care what this is.  I’m thinking that we pick whatever 
people think that the current style is and give folks a fixed period to debate 
changes.

  2. create some tools

These tools should help people conform to the style.

Primarily, what is needed is a tool with appropriate configuration that runs on 
the command line — e.g., mach reformat …  clang-format is looking like a good 
candidate for C/C++, it just needs a configuration.  For JavaScript, I’ve used 
the python js-beautify, but it’s pretty light on configuration options, it 
might need some hacking to make it better.

Ideally though, there should be set of configuration files for common editors.  
I’m certain there are plenty out there already.  Let’s bring them all together 
(attaching the files 
https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style might be 
enough).

  3. reformat everything

Take the command line tool and run it over all the code.  I realise that this 
is the contentious part, but you don’t get the real benefits until you do this.

Once you do this, it’s safe to reformat files at any time without messing with 
parts of files that you haven’t touched.  This is important bec

Re: A proposal to reduce the number of styles in Mozilla code

[Mike Hoye]

On 1/6/2014, 8:05 PM, Karl Tomlinson wrote:

The bug is hidden almost as well by conversion of only indentation.

   if (condition1)
 if (condition2)
   foo();
 else
   bar();

Sure, you could argue that style conversion makes the actual
behaviour clearer, but you'd have to know the intended behaviour
to know there was a bug.

If we have a tool to skip the style change on any such unclear
situations, then perhaps we can proceed more safely.


A syntactic change that's small, easy to review and limited to one part 
of one file, you say?


So as you describe it, a tool that backs off and flags ambiguities like 
this for human review would also be a tool that generates an _excellent_ 
set of Good First Bugs.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mozilla style guide issues, from a JS point of view

[Mike Hoye]

On 1/7/2014, 10:44 AM, Gervase Markham wrote:
  It would be very interesting for someone to see if any of the 
references Mike Hoye gives explain _which_ types of change lead to 
loss of productivity. For example, it could be that brace style does, 
and line length does not. 


I've been digging into the research style and formatting questions a 
bit, and this is what I have so far.


Short version:

- Indent with 4 spaces,
- use CamelCase,
- bracing style doesn't matter,
- consistency is The Most Important Thing.

Those are all consistently-replicated results. I don't have anything 
about line-length yet; I'm working on it.


The details:

On Spacing and indentation: Steve McConnell, in his book "Code 
Complete", says that "S ubjects scored 20 to 30 percent higher on a test 
of comprehension when programs had a two-to-four-spaces indentation 
scheme than they did when programs had no indentation at all. [...] The 
study concluded that two-to-four-space indentation was optimal. 
Interestingly, many subjects in the experiment felt that the six-space 
indentation was easier to use than the smaller indentations, even though 
their scores were lower. That’s probably because six space indentation 
looks pleasing. But regardless of how pretty it looks, six-space 
indentation turns out to be less readable. This is an example of a 
collision be tween aesthetic appeal and readability."


I've ordered a copy of his book, to figure out what the original source 
material actually says, but my understanding is that Python standardized 
on four-space indentation because of these results.


Brace style:  McConnell suggests - citing the Soloway and Ehrlich paper 
I mentioned, and others, that the specific brace style hasn't been 
demonstrated to matter all that much, provided it is always used 
consistently. Inconsistent bracing (exactly like every other 
inconsistently-applied coding style...) is what sends your thought 
process off into a ditch.


On CamelCase v. underscore_delimited variable naming and comprehension: 
Bonita Sharif and Jonathan Maletic at Kent State have concluded that - 
with some caveats about novice programmers - there's not a big 
difference in comprehension and accuracy between the two. That paper is 
here:


http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf

However, a related paper available here - 
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5090039 - (don't 
have the full paper, sorry) concludes that among experienced 
programmers, CamelCase, not under_score,  is measurably the right thing.


So, there you go.


- mhoye



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mozilla style guide issues, from a JS point of view

[Mike Hoye]

On 1/7/2014, 3:22 PM, Adam Roach wrote:


Since people are introducing actual research information here, let's 
run some numbers. According to Paterson et. al. [1], reading 
comprehension speed is actively hindered by lines that are either too 
short or too long, which they define as 9 picas (1.5 inches) and 43 
picas (~7 inches), respectively. Comprehension is significantly faster 
at 19 picas (~3 inches). 
[...]

[1] http://psycnet.apa.org/journals/xge/27/5/572/


I found some other citations about this as well - 
http://www.humanfactors.com/downloads/feb03.asp#kath  among others - but 
they all measure people reading English, not code. I haven't been able 
to find any that are specifically on-point for coding, but I'm still 
looking.


2 v. 4 spaces: more on that shortly.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bug 641509

[Mike Hoye]

On 1/7/2014, 11:40 AM, Matteo Sisti Sette wrote:


Oh now I see, 'the *confusion* of the "OMG YOUR COMPUTER IS 
INFECTED BY A VIRUS" messages were causing', that's the point! LOL


Yeah, I think we're done here.


-  mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mozilla style guide issues, from a JS point of view

[Mike Hoye]

On 1/7/2014, 3:46 PM, Mike Hoye wrote:



2 v. 4 spaces: more on that shortly.


An update on the research: Earlier, I said "four spaces" flat out, based 
on some conversations with researchers, but since then all the research 
I've been able to track down seems to cite the same paper. That paper 
says that two to four spaces of indentation results in better code 
comprehension than zero (obvs.) or 6+ spaces.


That paper is here: http://www.cs.umd.edu/~ben/papers/Miara1983Program.pdf

It also says that as long as it's consistent, block style doesn't 
matter, but that's not the most interesting thing here.


There are two things I've found while digging this stuff out that are 
really, really cool.


First of all: Perceived efficiency and real efficiency aren't the same 
thing at all. People  asked to rate what codebase they found most 
pleasant and efficient to work with, consistently rating 6 or more 
spaces very higher than 2-4 spaces, but when you put those people in 
front of an eye tracker and a stopwatch, what they perceive as best 
isn't what actually works best.


It echoes this classic Ask Tog article from the 1989, about clicking 
icons with mouse v. keyboard shortcuts - People who think the keyboard 
is faster are measurably wrong, because their brains actually don't 
remember the time it takes to recall a key sequence, instead of clicking 
a button.


http://www.asktog.com/TOI/toi06KeyboardVMouse1.html

The other thing that's probably more important from a community 
engagement or developer-migration perspective is that real complexity 
and perceived complexity are also two entirely different things. A 
dirt-simple program with crappy formatting, or even just a new codebase 
in a format that's new to you, will be perceived as much more complex 
and _become much harder to understand_ than a genuinely complicated 
program with a clean, well-structured codebase.


Which is all to say that I think this is kind of important.

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mozilla Location Services - Heads up

[Mike Hoye]

On 2/3/2014, 10:08 AM, Hanno Schlichting wrote:

Yes. You can read more about the API at:


We really need an ARG and some badges for this, to give people some sort 
of incentive to wander all over the place.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Mike Hoye]

On 2/11/2014, 10:19 AM, Dāvis Mosāns wrote:

What? Drop MathML?
While you're not doing much to endear anyone to your position here, my 
understanding is that we're not dropping MathML and we'll still take 
patches from people who'd like to improve it.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Always brace your ifs

[Mike Hoye]

On 2/22/2014, 1:04 PM, Jet Villegas wrote:

goto ftw;

I have to admit, I was very surprised to learn that:

- Using both -Wall and -Wextra doesn't get you -Wunreachable-code.
- The Clang manual lists documenting any of that that as a "todo".



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Why are images that are uploaded in Pinterest and Instagram modified in terms of size and pixel colors?

[Mike Hoye]

On 2014-02-28, 11:53 AM, Usman Ehtesham wrote:

When images are uploaded in Pinterest and Instagram, the size of the images get 
modified and so do the colors (within a ranges of +/- 10 pixels). Are images 
modified to align the images as a grid as seen in Pinterest and Instagram? If 
yes, how do they do it done?

Hi, Usman -

Instagram does this on-device, as far as I understand it, and Pinterest 
does it on the server side, probably with one of the ImageMagick tools 
or something a lot like them.


You can learn a bit more about those tools here: http://www.imagemagick.org/

Either way that stuff isn't handled by Firefox itself, so this isn't the 
right forum to answer questions about them.


The Instagram help center is here: http://help.instagram.com/

Pinterest's is here: https://help.pinterest.com/home

Good luck.

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Overview of how web-exposed objects are implemented

[Mike Hoye]

On 2014-03-29, 1:32 AM, Boris Zbarsky wrote:
Someone asked me today whether we have any sort of high-level overview 
of how web-exposed objects are implemented.  I didn't know of any, so 
I put together a start at 
. 
 Please feel free to edit if you can (karma > 75??) or send me 
feedback directly and I'll incorporate it.


I've lowered the karmic threshold for wiki edits to 30, which seems 
casually achievable; 25 semi-regular contributors are already there, and 
another dozen or so are close.


At the moment Neil Rashbrook (196), Benjamin Smedberg (178)  and Vlad 
Vukicevic (157) are the most karmically advanced among us, and can look 
forward to being reincarnated as something really cool. The average is 
still pretty low, though, so those of you who haven't been looking into 
Ask.m.o now and then should expect to be coming back as earthworms or 
field mice or something.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox build (Nightly) thread with root permission

[Mike Hoye]

On 2014-04-02, 1:46 AM, Paul wrote:

I strongly suspect this happens due to the permission issue while Nightly does 
not allow me to gain root privileges.

However, this is necessary for me to complete my experiment. How can I obtain a 
decent permission while I do this?


strace -f should see you right as far as specifically diagnosing what's 
failing is concerned;


I reiterate that this is a terrible idea - see here 
https://bugzilla.mozilla.org/show_bug.cgi?id=353203 for just a taste as 
to why, and please don't deploy whatever you're doing here to a 
production multi-user system. But still, good luck?


Maybe we could give you better advice if you could tell us a bit more 
about what you're trying to do with your experiment.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Policy for disabling tests which run on TBPL

[Mike Hoye]

On 2014-04-07, 11:12 AM, Ted Mielczarek wrote:
It's difficult to say whether bugs we find via tests are more or less 
important than bugs we find via users. It's entirely possible that 
lots of the bugs that cause intermittent test failures cause 
intermittent weird behavior for our users, we simply don't have any 
visibility into that.


Is there a way - or could there be a way - for us to push builds that 
generate intermittent-failure tests out to the larger Mozilla community?


And, more generally: I'd love it if we could economically tie in 
community engagement to our automated test process somehow.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Oculus VR support & somehwat-non-free code in the tree

[Mike Hoye]

On 2014-04-15, 12:47 AM, Andreas Gal wrote:

Vlad asked a specific question in the first email. Are we comfortable using 
another open (albeit not open enough for MPL) license on trunk while we rewrite 
the library? Can we compromise on trunk in order to innovate faster and only 
ship to GA once the code is MPL friendly via re-licensing or re-writing? What 
is our view on this narrow question?



While I support the pragmatic approach here - if we're rewriting the  
while building things on top of it, what is the fallback position if the 
library rewrite

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Oculus VR support & somehwat-non-free code in the tree

[Mike Hoye]

On 2014-04-15, 10:25 AM, Mike Hoye wrote:

On 2014-04-15, 12:47 AM, Andreas Gal wrote:
Vlad asked a specific question in the first email. Are we comfortable 
using another open (albeit not open enough for MPL) license on trunk 
while we rewrite the library? Can we compromise on trunk in order to 
innovate faster and only ship to GA once the code is MPL friendly via 
re-licensing or re-writing? What is our view on this narrow question?



While I support the pragmatic approach here - if we're rewriting the 
[library - mh]  while building things on top of it, what is the 
fallback position if the library rewrite


... goes sideways for technical or legal reasons?  "A plan B we can live 
with" seems like a deciding factor here.



Also, the window-close button being right next to the send button in 
Thunderbird turns into a real problem after your third coffee, let me 
tell you.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Policing dead/zombie code in m-c

[Mike Hoye]

On 2014-04-25, 3:31 AM, Henri Sivonen wrote:

On Thu, Apr 24, 2014 at 4:20 PM, Benoit Jacob  wrote:

   * How should we identify code that we build but that isn't used
anywhere?

I'm afraid we need humans for that.

Yeah, but how do we get humans to do that?

We ask them! There are thousands of people out there who want to help us 
do stuff, if we can give them the right stuff to do.


Noob question here: how accessible is the profiling process, and can 
we/would it be useful to make that participatory?


If we ask a thousand people to run a nightly under a profiler for a few 
days and aggregated the results, would that be valuable information?


- mhoye




___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Policing dead/zombie code in m-c

[Mike Hoye]

On 2014-04-25, 11:12 AM, Trevor Saunders wrote:

On Fri, Apr 25, 2014 at 10:42:43AM -0400, Mike Hoye wrote:

If we ask a thousand people to run a nightly under a profiler for a few days
and aggregated the results, would that be valuable information?

If the users are a good distribution and we collect a list of every
function we run we should be able to compare that to a list of things
that go into libxul, and maybe we'd find something useful.


I guess the question becomes how practical it is to set this up and run 
it, vs. the anticipated value of the results.


(Whether it's a good fit for this task or not, community-assisted 
tooling is something we can do that not a lot of other orgs can, and I 
think it's worth remembering that we've got that potentially very heavy 
club in the bag.)



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS.File design issue from bug 961080 (making downloads respect umask)

[Mike Hoye]

On 2014-04-25, 2:41 PM, Ralph Giles wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2014-04-25 11:08 AM, Zack Weinberg wrote:

Against these (particularly the third) was the claim that this API
is only useful to the download manager.

Forgive the derail, but why does the download manager need to make
things executable?
Because people download executable files with the expectation that they 
can easily execute them.


Probably less than a tenth of a percent of the world knows or cares what 
a filesystem permission is, linux users or not; if we flip that bit then 
we're the browser that breaks downloads and people will just switch to 
one that works.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide

[Mike Hoye]

On 2014-05-13, 10:47 AM, Benjamin Smedberg wrote:

On 5/12/2014 4:07 PM, Boris Zbarsky wrote:


So I'd like to propose that our C++ style require one-arg 
constructors to be marked explicit unless there's a clear comment 
explaining why the constructor is implicit.
Seems there's general agreement. Please make this change to the style 
guide.


Anyone here up for doing some static analysis to detect and fix 
in-tree instances of this?

If you think this would be a good bug for a contributor, file+flag please.

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Hyperlink Auditing ()

[Mike Hoye]

On 2014-05-20, 12:37 PM, Steve Fink wrote:

On Fri 16 May 2014 07:45:22 AM PDT, Justin Dolske wrote:

Private Browsing mode is about not storing _local_ data from your
activities. It is explicitly not an "anti tracking" mode because
that's extremely difficult-to-impossible to do robustly just on the
client, and would be a misleading claim and/or result in a browser
most people would think is broken. E.G. as already noted in this
thread, sites can already do this without .

When you're shopping for an engagement ring, why would you want to
prevent the jewelry vendor from knowing that you're shopping, or from
knowing who you are?
Because being able to more uniquely identify you makes it easier to game 
you. You should always be in private browsing mode when you're shopping 
for airplane tickets, for example.


- mhoye






___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates

[Mike Hoye]

On 2014-05-28, 9:07 PM, Joshua Cranmer 🐧 wrote:


Two more possible rationales:
1. The administrator is unwilling to pay for an SSL certificate and 
unaware of low-cost or free SSL certificate providers.
2. The administrator has philosophical beliefs about CAs, or the CA 
trust model in general, and is unwilling to participate in it. 
Neglecting the fact that encouraging click-through behavior of users 
can only weaken the trust model.


3. The administrator doesn't actually believe SSL certs protect you from 
any real harm, and is generating a cert using the least effort possible 
to make a user-facing dialog box go away.


It's become clear in the last few months that the overwhelmingly most 
frequent users of MITM attacks are state actors with privileged network 
positions either obtaining or coercing keys from CAs, using attacks that 
the CA model effectively endorses, using tech you can buy off the shelf. 
In that light, it's not super-obvious what SSL certs protect you from 
apart from some jackass sniffing the coffeeshop wifi.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: bugzilla can now show bugs that have been updated since you last visited them

[Mike Hoye]

On 2014-06-04, 2:34 AM, Byron Jones wrote:
thanks to dylan's work on bug 489028, bugzilla now tracks when you 
view a bug, allowing you to search for bugs which have been updated 
since you last visited them.


This is great work. Thank you, Dylan!

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I've seen the mozilla git mirror in github, I want all the tags storage in github. can that to be possible?

[Mike Hoye]

On 2014-06-16, 10:39 PM, luoyongg...@gmail.com wrote:

I am saying about
https://github.com/mozilla/gecko-dev

After that,

I am also looking for comn-central git mirror.

This may be what you are looking for:

https://github.com/mozilla/releases-comm-central

I don't know if it is considered canonical - I will ask - but there is a 
lot of activity there.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Mentors now have their own Bugzilla field.

[Mike Hoye]

Hi, everyone -

We've just wrapped up big migration of the mentored bug information in 
Bugzilla from [mentor=person] in the whiteboard to bug mentors being 
their own field.


Most of that change was done automatically and silently, for which we 
can thank glob, dkl and their usual quietly-professional aplomb. A lot 
of the data was messy, though, and I had to finish a few hundred bugs 
worth of migration manually; this wasn't even a little bit silent. Some 
of you got a lot of bugmail from me today, and in particular I'd like to 
remind members of the compatibility team that you can't expense a mob 
hit under current accounting best practices.


This means a couple of things, most of which are nice and one of which 
is not.


- We'll have much easier time figuring out much and how valuable 
mentoring and good first bugs really are, presently and historically. 
More about this is forthcoming, with all kinds of fancy graphs.
- Building around mentored/good-first bugs just became simpler and more 
reliable.

- Needinfo -> Mentor is on the way, which should be good.

The thing that's not nice is that I should have done a better job of 
preannouncing this change. If you've built anything that relied on 
searching for "whiteboard contains mentor=whatever", it's broken now.


Fixing any breakage that has occurred should be straightfoward; note that

$> curl https://bugzilla.mozilla.org/rest/bug/##?include_fields=mentors

returns JSON that looks like this:

{"bugs":[{"mentors":["someb...@somewhere.org"],"mentors_detail":[{"email":"someb...@somewhere.org","real_name":"Some 
Body 
[:somebody]","name":"someb...@somewhere.org","id":123456}]}],"faults":[]}




Thanks,

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to Visual Studio 2013

[Mike Hoye]

On 2014-08-27 10:22 AM, Gian-Carlo Pascutto wrote:

One issue related to the discussion in bug 914596 is that it's harder to
find the non-latest-version of the Express version. That is, if you
install Express now, you get SP3.

It's probably possible to get SP2 anyhow, but I couldn't easily find a way.
It shouldn't be more than one click to get from an MDN getting-started 
page to the software you need.


I'll ask Mike Connor about this, but I _think_ we have the kind of 
relationship with Microsoft where we can ask them for a static link to 
some version of VSExpress when the time comes, so that it's easy for our 
contributors to get spun up.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Continued support for ESR

[Mike Hoye]

On 2014-09-10 10:32 PM, Philip Chee wrote:

“New personal versions of Firefox are released roughly every six weeks,”
writes Oracle's Steven Chan. “It is impractical for us to certify these
new personal versions of Firefox with the Oracle E-Business Suite
because a given Firefox release is generally obsolete by the time we
complete the certification.”

But then...


Also welcome
will be Oracle's policy of certifying any point releases of ESR on the
day of their release.



I don't understand.

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: easiest way to contribute .

[Mike Hoye]

On 2014-09-25 10:23 AM, Mike Habicher wrote:

Hello!

Mozilla has many projects on the go. This site 
http://whatcanidoformozilla.org/ might help you find something you're 
interested in.


In addition, if you're interested in working on the Firefox codebase, 
please take a look Bugs Ahoy:



http://www.joshmatthews.net/bugsahoy/

... and let me know if you find something that interests you!

This page: https://developer.mozilla.org/en-US/docs/Introduction

... has some good information about getting your development environment 
set up so you can contribute to Firefox.


Thanks, and good luck.


- mhoye

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Documenting uses of Github at Mozilla

[Mike Hoye]

On 2014-09-30 7:38 PM, Karl Dubost wrote:

Basically embrace the unknown. Accept it. And create meaningful links in 
between projects when these links matter for people to follow a hypertext paper 
trail.



I know I spend a lot of time beating this drum and you're all tired of 
hearing it, but I still think it's important.


Embracing the unknown sounds fun and easy, but we should keep in mind 
that services that we don't control - or as a minimum have a contractual 
relationship with - can just go away at any moment.


There are two things about Eric's proposal that I'm interested in. 
Obviously making projects easier to find makes them easier for everyone 
to participate in. But it would also be nice to have a list of stuff 
that's hosted by third parties that has become important enough that it 
should be backed up somewhere internal, preferably somewhere with 
disaster recovery and business continuity plans.


Having to scramble to recover from data loss - particularly around 
source or bug tracking - is a miserable experience we should try to avoid.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Documenting uses of Github at Mozilla

[Mike Hoye]

On 2014-10-01 12:16 PM, Ehsan Akhgari wrote:

On 2014-10-01, 11:59 AM, Ralph Giles wrote:

On 2014-10-01 7:17 AM, Mike Hoye wrote:

Having to scramble to recover from data loss - particularly around
source or bug tracking - is a miserable experience we should try to 
avoid.


Perhaps http://gitmirror.mozilla.org/ should be our project directory.


That is a great idea!


Particularly if we could flesh those entries out with a descriptive 
paragraph or two, for sure.  It seems like that could easily be 
automated, too. I think the author of that intranet page has left us for 
Stripe a while ago. Who owns it now?




- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Documenting uses of Github at Mozilla

[Mike Hoye]

On 2014-10-01 12:16 PM, Ehsan Akhgari wrote:

On 2014-10-01, 11:59 AM, Ralph Giles wrote:

On 2014-10-01 7:17 AM, Mike Hoye wrote:

Having to scramble to recover from data loss - particularly around
source or bug tracking - is a miserable experience we should try to 
avoid.


Perhaps http://gitmirror.mozilla.org/ should be our project directory.


That is a great idea!


There's a proposal to decommission gitmirror.m.o. in

https://bugzilla.mozilla.org/show_bug.cgi?id=910040

... in favor of git.m.o for major projects. I've made the case there 
that instead, we should keep it as an automated index of "tier-2" GitHub 
repos and cc'ed Ehsan and Ralph on it, for initiating this discussion 
and issuing the first pull request to the old updater script respectively.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Documenting uses of Github at Mozilla

[Mike Hoye]

On 2014-10-06 12:31 PM, Tantek Çelik wrote:

Since all these repo links are likely to become unfindable in email...

Contributions welcome: https://wiki.mozilla.org/Github


Ok, I've added all the URLS mentioned here to the bottom of the list.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Mike Hoye]

On 2014-10-14 10:14 PM, Ehsan Akhgari wrote:

On 2014-10-14, 10:09 PM, Mike Hommey wrote:


I'm not saying we shouldn't strive for better, but I'm questioning 
the fact

that download size would be affecting our growth. If the download size
of our competitors is not affecting theirs, why would it affect ours?
(and again, the premise is an interrogation)
That's a fair objection. One possible explanation for that would be 
the hypothesis that they have more directly focused on markets where 
broadband Internet is prevalent through, let's say TV ads in the case 
of Chrome.  Of course I don't know whether that's true, but I don't 
think we can necessarily assume a similar growth impact potential here 
for different browsers.
For whatever it's worth I think we're conflating bits-on-the-disk with 
bits-on-the-wire here, which isn't necessarily the how things need to work.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The worst piece of Mozilla code

[Mike Hoye]

On 2014-10-16 8:32 AM, Nicholas Nethercote wrote:

Hi,

I was wondering what people think is the worst piece of code in the
entire Mozilla codebase. I'll leave the exact meanings of "worst" and
"piece of code" unspecified...

Currently or ever?

I mean, if you find somebody in their office today curled up in a ball, 
rocking back and forth and muttering "mork, mork, mork" over and over 
again, that person's having a bad flashback. Call for help, stay with 
them. Tell them we've got sqlite now and it's going to be OK.


Don't mention Thunderbird.

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to Visual Studio 2013

[Mike Hoye]

On 2014-10-20 11:44 AM, Gijs Kruitbosch wrote:

Hi,

Can you or someone else in the know update 
https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/Windows_Prerequisites 
and friends,

Working on it.

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to Visual Studio 2013

[Mike Hoye]

On 2014-10-20 11:56 AM, Ehsan Akhgari wrote:

On 2014-10-20 11:44 AM, Gijs Kruitbosch wrote:

Hi,

Can you or someone else in the know update
https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/Windows_Prerequisites 


and friends, or (if you don't like wiki software, don't want to create
an account, or have other reasons not to want to do this...) provide
instructions on how to use vs2013 and mozillabuild on this thread so
someone else can update the docs?


What is specifically missing from the docs?


Basically everything. It's compounded by the fact that there a few 
different editions of Visual Studio Express available whose naming 
scheme is opaque and only some of which (as far as I can tell) will work.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: power use on Yosemite

[Mike Hoye]

On 2014-11-01 3:47 PM, Andreas Gal wrote:
> Ideas welcome.

Before he left, Taras was discussing power consumption analysis with 
Abram Hindle, a researcher at the university of Alberta. Some of 
Hindle's work is here:


http://softwareprocess.es/static/GreenMining.html

Specifically this paper: "Green Mining: A Methodology of Relating 
Software Change to Power Consumption"


http://softwareprocess.es/a/green-change-web.pdf

He's written a comparable paper targeting Fennec, and has interesting 
preliminary findings. From his email to me:


"We found that blocking on a slow connection used consistently more 
power than idle. This could be solely due to network traffic, but 
network traffic was very periodic (1 packet in and 1 packet out per 
second), thus much of the work could likely be attributed to the 
animated spinner. The difference was not very large, but it was 
statistically significant."


I spoke to him today at CSER, and despite Taras' departure he'd like to 
continue this work that would give us a very fine-grained understanding 
of where your battery's going, and which we could integrate into our 
build infra.


So that's interesting. I'll forward his papers to you directly.

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: power use on Yosemite

[Mike Hoye]

On 2014-11-03 12:32 PM, Martin Thomson wrote:

On 02/11/14 18:13, Mike Hoye wrote:

"We found that blocking on a slow connection used consistently more
power than idle. This could be solely due to network traffic, but
network traffic was very periodic (1 packet in and 1 packet out per
second), thus much of the work could likely be attributed to the
animated spinner. The difference was not very large, but it was
statistically significant."


That suggests that it could be a result of us not having QUIC and 
Google Sheets not being friendly to TCP-based usages.


These results come from a Fennec profiling exercise run against a 
generic but tightly throttled web server, not desktop/gdocs.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Effective Community Building Practices - Portland, Friday morning.

[Mike Hoye]

Last reminder, everyone: 9:00 to 11:00 on the Friday morning in the 
Marriott Waterfront Hotel's Oregon ballroom, I'll be hosting an 
Engineering-focused community-building session - "Effective Community 
Building Practices".


The goals are going to be:

- Relating known best-practices: what measurably works, what measurably 
doesn't, what metrics matter and what moves the needle.
- Talks about goals, successes and failures from different corners of 
Mozilla, and

- Tactics for achieving our goals in 2015.

You'll love it, we have numbers and everything.

Despite my certainty that you'd all love to listen to me talk 
uninterrupted for two solid hours, we've also got a solid lineup of 
speakers including (so far) Mike Conley, Manish Goregaokar, Soumya Deb. 
Joel Maher, Clint Talbert, Nick Alexander, Josh Matthews and Lukas Blakk.


We're clearly tight for time and I don't want to waste any of yours, so 
I'm asking everyone to come into that meeting with a sense of what their 
2015 community-growth goals look like and to be ready to talk 
boots-on-the-ground tactics.


Victory conditions here are that everyone to leave knowing what works 
and what to avoid in pursuing their goals, who to ask for help, and to 
know who each other are well enough to steer contributors and questions 
around Mozilla.


We've still got some headroom for more speakers; coordination is here:

https://etherpad.mozilla.org/Portland-Community-Building

... because who _doesn't_ love etherpads, right? Right?

Hope to see you there,

- mhoye

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Support for building with Visual C++ 2012 removed from Gecko 37

[Mike Hoye]

On 2015-01-06 4:33 PM, Ehsan Akhgari wrote:

I updated <
https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code>
accordingly.
I've updated our Windows Build Prerequisites docs to reflect this 
change, and I'm passing this information on to our community channels.


https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Support for building with Windows SDK <8.1 removed from Gecko 37

[Mike Hoye]

On 2015-01-08 12:15 AM, Botond Ballo wrote:

​Building Firefox​*for*  Windows XP (and running it on Windows XP) is
unaffected.

Building Firefox*on*  Windows XP, however, is - I believe - no longer
supported, and in fact hasn't been since we bumped the minimum required
MSVC version to 2012, since 2010 is the latest MSVC version that XP can run.

VS2013 won't run* on Windows earlier than Win7, Service Pack 1.

I'm revisiting our docs in light of this to figure out what our real 
minimum hardware/ram/disk requirements are. The temptation to start 
adding "If you try to build Firefox with 2 gigs of RAM, you're gonna 
have a bad time" memes to the docs is severe.


- mhoye

* - (Well, not entirely true - it'll run on Server 2008 R2, but that's 
x64 only and also will never actually happen.)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Support for building with Windows SDK <8.1 removed from Gecko 37

[Mike Hoye]

On 2015-01-09 8:59 AM, Neil wrote:


2GB builds, although I expect it's on the slow side. 1GB isn't enough 
though, unless you enable shared gkmedias and js (and shared js builds 
are broken anyway because we don't link to js when we should).


1GB is the bare minimum require to run VS2013 Community at all, and 
that's only for Win7x86 nonvirtual. On VMs you need 1.5 min, say the 
specs, and x64 are 2GB.


I've put a 2GB minimum in the docs; I'm curious what the real disk space 
minimums are for Linux? Those numbers haven't been updated in a while, 
looks like.


- mhoye


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Detecting 32 or 64-bit Firefox build from privileged JS

[Mike Hoye]

Flag the easy ones as [good first bug]s and cc me, please. These are the 
little fish we throw back in the water to reel in the big fish.


- mhoye


On 2015-02-24 7:28 AM, David Rajchenbach-Teller wrote:

It might be useful to add this to OS.Constants.Sys, which is available
to all threads. It's basically one line of code in
dom/system/OSFileConstants.cpp


We don't know what we will support in the future so I wanted a future proof 
solution... adding is64bit to nsIXULAppInfo was unbelievably easy.



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

32-bit Windows builds will fail.

[Mike Hoye]

As far as I can tell from Bug 1110236 and my own testing, it's no longer 
possible to build Firefox on 32-bit Windows systems. Recent changes to 
how we use our linker will reliably cause the error described in the bug.


I've filed bug 1137346 to that effect; I don't see an answer, and I 
suspect building on 32-bit Windows is a thing of the past.


I believe this is an unexpected side effect of the recent libXUL 
consoldiation; I haven't been able to find anyone anticipating this in 
Bugzilla, and we certainly didn't update the relevant documentation. I 
know that this is a problem for exactly zero of Mozilla's employees, but 
it's potentially a deal-breaker for many of our contributors. Asking 
civilians to upgrade their OS in order to keep participating is a really 
big ask, and we've accidentally forced this upgrade-or-go-away decision 
on some of our community members with zero advance warning.


I was really happy that the burden on community participantion was 
considered when we moved to VS2013 as the windows minimum environment. 
That said, I don't know how many contributors this affects, and I can 
guess that it's too late to roll back the libXUL changes at my 
numerically-unsupported request.


Instead, I propose that we stand up a variety of old, slow, minimum-spec 
"approved" development boxes, build on them daily. If forward progress 
means we need to abandon a category of developers' machines, I ask that 
we try to do that with as much transparency and advance notice as we'd 
grant a category of users in the same position.


Thanks.

- mhoye

https://bugzilla.mozilla.org/show_bug.cgi?id=1110236
https://bugzilla.mozilla.org/show_bug.cgi?id=1137346
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 32-bit Windows builds will fail.

[Mike Hoye]

On 2015-02-27 8:46 AM, Ben Hearsum wrote:

On 2015-02-26 05:57 PM, Mike Hoye wrote:

Instead, I propose that we stand up a variety of old, slow, minimum-spec
"approved" development boxes, build on them daily. If forward progress
means we need to abandon a category of developers' machines, I ask that
we try to do that with as much transparency and advance notice as we'd
grant a category of users in the same position.

Monitoring things that only build on a nightly basis has proven to be
terribly difficult. Nightly only jobs (that don't have equivalent CI
jobs) are hidden on treeherder/tbpl, and issues tend to go unnoticed for
weeks. Bustage to jobs like this isn't usually cause for backouts either.
I've had a couple of conversations with engineers and managers about 
this in various fora. Consensus seems to be that this is kind of a crap 
situation to have fallen into inadvertently and my heart's in the right 
place but the cost-benefit fixing this is not clear.


And that's without considering backing out the relevant changes, which 
we'd need a fantastic reason I don't have to justify. So barring some 
significant command-line-option insight in the next few days I'm going 
to update the relevant documentation, wontfix 1137346, and put some cron 
jobs in some VMs in the hope that this class of problem doesn't sneak up 
on us again.




- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?

[Mike Hoye]

On 2015-04-08 3:08 PM, Seth Fowler wrote:



Can we do this?

Any better ideas?
I filed 1013371 a while back asking for something not quite identical 
that might meet your needs.


"Automatically create clean profiles when -P specifies nonexistent profile."

- mhoye


https://bugzilla.mozilla.org/show_bug.cgi?id=1013371
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Mike Hoye]

On 2015-04-15 10:03 AM, commodorej...@gmail.com wrote:

On Wednesday, April 15, 2015 at 6:56:48 AM UTC-7, Joseph Lorenzo Hall wrote:

If you're addicted to cleartrext, the future is going to be hard for you...

Only because people like you insist on trying to push it across-the-board, 
rather than let webmasters make their own decisions.
Webmasters are already restricted in how they can run their services in 
many ways, some standards-based, some inherent to the web as we find it 
in the wild.


For what it's worth I think that the fact that it is (at present) way 
more difficult to obtain, install, and update a certificate for a web 
server than it is to obtain, install and update a web server means that 
_mandating_ HTTPS would represent a real barrier to participation in a 
free and open Web.


Having said that, "deprecated" clearly doesn't mean "prohibited", and 
the Let's Encrypt's "How It Works" page suggests that setting up a cert 
won't be all that difficult in the near future. So, while you may be 
right that the benefits here seem to be all client side and the up-front 
costs seem to be all server-side, it looks like work is well underway to 
reduce server-side costs to almost nothing. Moving from "TLS if the 
server wants to" to "TLS is what the client expects" is a meaningful 
change in incentive structure underneath web security, and sounds like 
the right thing to me.


- mhoye

* https://letsencrypt.org/howitworks/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Mike Hoye]

On 2015-04-17 12:20 PM, Anne van Kesteren wrote:

On Fri, Apr 17, 2015 at 6:13 PM,   wrote:

As a non-tech person, the only thing I know is https means my browser runs even 
slower on DSL.

This has already been addressed earlier in the thread. HTTPS has
negligible performance impact. See e.g.:

   https://istlsfastyet.com/
I don't see where that document speaks to the impact of TLS on caching 
proxies, which I'm guessing is the source of the performance hit Andrew 
mentions.


It's been a while since I've looked, but in Canada (and probably other 
geographically large countries) the telcos/ISP with large exurban/rural 
client bases used to use caching proxies a lot.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Mike Hoye]

On 2015-04-21 6:43 AM, skuldw...@gmail.com wrote:
I know, not that well explained and over simplified. But the concept 
is hopefully clear, but in case it's not...
For what it's worth, a lot of really smart people have been thinking 
about this problem for a while and there aren't a lot of easy buckets 
left on this court. Even if we had the option of starting with a clean 
slate it's not clear how much better we could do, and scrubbing the 
internet's security posture down to the metal and starting over isn't 
really an option. We have to work to improve the internet as we find it, 
imperfections and tradeoffs and all.


Just to add to this discussion, one point made to me in private was that 
HTTPS-everywhere defangs the network-level malware-prevention tools a 
lot of corporate/enterprise networks use. My reply was that those same 
companies have tools available to preinstall certificates in browsers 
they deploy internally - most (all?) networking-hardware companies will 
sell you tools to MITM your own employees - which would be an acceptable 
solution in those environments where that's considered an acceptable 
solution, and not a thing to block on.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Excessive inbound bustage

[Mike Hoye]

On 2015-04-21 4:56 PM, jmath...@mozilla.com wrote:

I think we're being bit too sensitive here, I'm sure we can all handle a little 
public shaming on stuff like this.
We should not do this. There aren't a lot of things that will rot 
organizational morale and make people risk-averse faster and more 
permanently than publicly shaming people who make mistakes.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Treeherder UI performance much worse in Nightly vs Chrome

[Mike Hoye]

On 2015-04-23 10:43 AM, Ed Morley wrote:

Scrolling fluidity/general app responsiveness of Treeherder is massively
worse in Nightly compared to Chrome. eg try this in both:
https://treeherder.mozilla.org/#/jobs?repo=mozilla-central

I asked some volunteers from the Reps to do an advocacy/evangelism 
experiment last quarter: ask people to try Firefox for two weeks, see if 
they stick with it, see what motivated them to switch back. Perceived 
performance on Windows machines was one of the main reasons people went 
back to Chrome. Scrolling jank was remarked on specifically.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform