Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla -
Bijgewerkt: 12 uur 19 min geleden

Liz Henry: How to test new features in Firefox 34 Aurora

do, 11/09/2014 - 21:40

If you’re a fan of free and open source software and would like to contribute to Firefox, join me for some Firefox feature testing!

There are some nifty features under development right now for Firefox 34 including translation in the browser, making voice or video calls (a feature called “Hello” or “Loop”), debugging information for web developers in the Dev Tools Inspector, and recent improvements to HTML5 gaming.

I’ve written step by step instructions on these
ways to test Firefox 34. If you would like to see what it’s like to improve a popular open source project, trying out these tasks is a good introduction.


First, Install the Aurora version of Firefox. It is best to set it up to use multiple profiles. That ensures you don’t use your everyday version of Firefox for testing, so you won’t risk losing your usual profile information. It also makes it easy to restart Firefox with a new, clean profile with all the default settings, very useful for testing. Sometimes I realize I’m running 5 different versions of Firefox at once!

To test “Hello”, try making some voice or video calls from Firefox Aurora. You will need a friend to test with. Or, use two computers that you control. This is a good task to try while joining our chat channels, #qa or #testday on; ask if anyone there wants to test Hello with you. The goal here is mostly to find and report new bugs.

If you test the translation infobar in Aurora you may find some new bugs. This is a fun feature to test. I like trying it on Wikipedia in many different languages, and also looking at newspapers!

If you’re a web developer, you may use Developer Tools in Firefox. I’m asking Aurora users to go through some unconfirmed bug reports, to help improve the Developer Tools Inspector.

If you like games you can test HTML5 web-based games in Firefox Aurora. This helps us improve Firefox and also helps the independent game developers. We have a list of demo games so you can play them, report glitches, and feel like a virtuous open source citizen all at once. Along the way you have opportunities to learn some interesting stuff about how graphics on the web can work (or not work).

Monster madness

These testing tasks are all set up in One and Done, Mozilla QA’s site to start people along the path to joining our open source community. This site was developed with a lot of community contribution including the design and concept by long-time community member Parul and a lot of code by two interns this summer, Pankaj and Maja.

Testing gives a great view into the development process for people who may not (yet) be programmers. I especially love how transparent Mozilla’s process can be. Anyone can report a bug, visible to the entire world in There are many people watching that incoming stream of bug reports, confirming them and routing them to developer teams, sometimes tagging them as good first bugs for new contributors. Developers who may or may not be Mozilla employees show up in the bugs, like magic . . . if you think of bugmail notifications as magic . . .

It is amazing to see this very public and somewhat anarchic collaboration process at work. Of course, it can also be extremely satisfying to see a bug you discovered and reported, your pet bug, finally get fixed.

Related posts:A culture of free as in free beer, trust, and ethical paymentJoy of unit testing
Categorieën: Mozilla-nl planet

Gervase Markham: Praise and Criticism

do, 11/09/2014 - 15:29

Praise and criticism are not opposites; in many ways, they are very similar. Both are primarily forms of attention, and are most effective when specific rather than generic. Both should be deployed with concrete goals in mind. Both can be diluted by inflation: praise too much or too often and you will devalue your praise; the same is true for criticism, though in practice, criticism is usually reactive and therefore a bit more resistant to devaluation.

– Karl Fogel, Producing Open Source Software

Wounds from a friend can be trusted, but an enemy multiplies kisses.

Proverbs 27:6

Categorieën: Mozilla-nl planet

Armen Zambrano: Run tbpl jobs locally with Http authentication ( - take 2

do, 11/09/2014 - 14:45
Back in July, we deployed the first version of Http authentication for mozharness, however, under some circumstances, the initial version could fail and affect production jobs.

This time around we have:

  • Remove the need for config files
    • Each production config had an associated config file
  • Prevented it from running in production environment
    • The only way to enable the developer mode is by appending --cfg
If you read How to run Mozharness as a developer you should see the new changes.
As quick reminder, it only takes 3 steps:
  1. Find the command from the log. Copy/paste it.
  2. Append --cfg
  3. Append --installer-url/--test-url with the right values
To see a real example visit this
Creative Commons License
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Categorieën: Mozilla-nl planet

Niko Matsakis: Attribute and macro syntax

do, 11/09/2014 - 13:33

A few weeks back pcwalton introduced a PR that aimed to move the attribute and macro syntax to use a leading @ sigil. This means that one would write macros like:

@format("SomeString: {}", 22)


@vec[1, 2, 3]

One would write attributes in the same way:

@deriving(Eq) struct SomeStruct { } @inline fn foo() { ... }

This proposal was controversial. This debate has been sitting for a week or so. I spent some time last week reading every single comment and I wanted to lay out my current thoughts.

Why change it?

There were basically two motivations for introducing the change.

Free the bang. The first was to “free up” the ! sign. The initial motivation was aturon’s error-handling RFC, but I think that even if we decide not to act on that specific proposal, it’s still worth trying to reserve ! and ? for something related to error-handling. We are very limited in the set of characters we can realistically use for syntactic sugar, and ! and ? are valuable “ASCII real-estate”.

Part of the reason for this is that ! has a long history of being the sigil one uses to indicate something dangerous or surprising. Basically, something you should pay extra attention to. This is partly why we chose it for macros, but in truth macros are not dangerous. They can be mildly surprising, in that they don’t necessarily act like regular syntax, but having a distinguished macro invocation syntax already serves the job of alerting you to that possibility. Once you know what a macro does, it ought to just fade into the background.

Decorators and macros. Another strong motivation for me is that I think attributes and macros are two sides of the same coin and thus should use similar syntax. Perhaps the most popular attribute – deriving – is literally nothing more than a macro. The only difference is that its “input” is the type definition to which it is attached (there are some differences in the implementation side presently – e.g., deriving is based off the AST – but as I discuss below I’d like to erase that distiction eventually). That said, right now attributes and macros live in rather distinct worlds, so I think a lot of people view this claim with skepticism. So allow me to expand on what I mean.

How attributes and macros ought to move closer together

Right now attributes and macros are quite distinct, but looking forward I see them moving much closer together over time. Here are some of the various ways.

Attributes taking token trees. Right now attribute syntax is kind of specialized. Eventually I think we’ll want to generalize it so that attributes can take arbitrary token trees as arguments, much like macros operate on token trees (if you’re not familiar with token trees, see the appendix). Using token trees would allow more complex arguments to deriving and other decorators. For example, it’d be great to be able to say:


where EncoderTypeName<foo> is the name of the specific encoder that you wish to derive an impl for, vs today, where deriving always creates an encodabe impl that works for all encoders. (See Issue #3740 for more details.) Token trees seem like the obvious syntax to permit here.

Macros in decorator position. Eventually, I’d like it to be possible for any macro to be attached to an item definition as a decorator. The basic idea is that @foo(abc) struct Bar { ... } would be syntactic sugar for (something like) @foo((abc), (struct Bar { ... })) (presuming foo is a macro).

An aside: it occurs to me that to make this possible before 1.0 as I envisioned it, we’ll need to at least reserve macro names so they cannot be used as attributes. It might also be better to have macros declare whether or not they want to be usable as decorators, just so we can give better error messages. This has some bearing on the “disadvantages” of the @ syntax discussed below, as well.

Using macros in decorator position would be useful for those cases where the macro is conceptually “modifying” a base fn definition. There are numerous examples: memoization, some kind of generator expansion, more complex variations on deriving or pretty-printing, and so on. A specific example from the past was the externfn! wrapper that would both declare an extern "C" function and some sort of Rust wrapper (I don’t recall precisely why). It was used roughly like so:

externfn! { fn foo(...) { ... } }

Clearly, this would be nicer if one wrote it as:

@extern fn foo(...) { ... }

Token trees as the interface to rule them all. Although the idea of permitting macros to appear in attribute position seems to largely erase the distinction between today’s “decorators”, “syntax extensions”, and “macros”, there remains the niggly detail of the implementation. Let’s just look at deriving as an example: today, deriving is a transform from one AST node to some number of AST nodes. Basically it takes the AST node for a type definition and emits that same node back along with various nodes for auto-generated impls. This is completely different from a macro-rules macro, which operates only on token trees. The plan has always been to remove deriving out of the compiler proper and make it “just another” syntax extension that happens to be defined in the standard library (the same applies to other standard macros like format and so on).

In order to move deriving out of the compiler, though, the interface will have to change from ASTs to token trees. There are two reasons for this. The first is that we are simply not prepared to standardize the Rust compiler’s AST in any public way (and have no near term plans to do so). The second is that ASTs are insufficiently general. We have syntax extensions to accept all kinds of inputs, not just Rust ASTs.

Note that syntax extensions, like deriving, that wish to accept Rust ASTs can easily use a Rust parser to parse the token tree they are given as input. This could be a cleaned up version of the libsyntax library that rustc itself uses, or a third-party parser module (think Esprima for JS). Using separate libraries is advantageous for many reasons. For one thing, it allows other styles of parser libraries to be created (including, for example, versions that support an extensible grammar). It also allows syntax extensions to pin to an older version of the library if necessary, allowing for more independent evolution of all the components involved.

What are the objections?

There were two big objections to the proposal:

  1. Macros using ! feels very lightweight, whereas @ feels more intrusive.
  2. There is an inherent ambiguity since @id() can serve as both an attribute and a macro.

The first point seems to be a matter of taste. I don’t find @ particularly heavyweight, and I think that choosing a suitable color for the emacs/vim modes will probably help quite a bit in making it unobtrusive. In constrast, I think that ! has a strong connotation of “dangerous” which seems inappropriate for most macros. But neither syntax seems particularly egregious: I think we’ll quickly get used to either one.

The second point regarding potential ambiguities is more interesting. The ambiguities are easy to resolve from a technical perpsective, but that does not mean that they won’t be confusing to users.

Parenthesized macro invocations

The first ambiguity is that @foo() can be interpreted as either an attribute or a macro invocation. The observation is that @foo() as a macro invocation should behave like existing syntax, which means that either it should behave like a method call (in a fn body) or a tuple struct (at the top-level). In both cases, it would have to be followed by a “terminator” token: either a ; or a closing delimeter (), ], and }). Therefore, we can simply peek at the next token to decide how to interpret @foo() when we see it.

I believe that, using this disambiguation rule, almost all existing code would continue to parse correctly if it were mass-converted to use @foo in place of the older syntax. The one exception is top-level macro invocations. Today it is common to write something like:

declaremethods!(foo, bar) struct SomeUnrelatedStruct { ... }

where declaremethods! expands out to a set of method declarations or something similar.

If you just transliterate this to @, then the macro would be parsed as a decorator:

@declaremethods(foo, bar) struct SomeUnrelatedStruct { ... }

Hence a semicolon would be required, or else {}:

@declaremethods(foo, bar); struct SomeUnrelatedStruct { ... } @declaremethods { foo, bar } struct SomeUnrelatedStruct { ... }

Note that both of these are more consistent with our syntax in general: tuple structs, for example, are always followed by a ; to terminate them. (If you replace @declaremethods(foo, bar) with struct Struct1(foo, bar), then you can see what I mean.) However, today if you fail to include the semicolon, you get a parser error, whereas here you might get a surprising misapplication of the macro.

Macro invocations with braces, square or curly

Until recently, attributes could only be applied to items. However, recent RFCs have proposed extending attributes so that they can be applied to blocks and expressions. These RFCs introduce additional ambiguities for macro invocations based on [] and {}:

  • @foo{...} could be a macro invocation or an annotation @foo applied to the block {...},
  • @foo[...] could be a macro invocation or an annotation @foo applied to the expression [...].

These ambiguities can be resolved by requiring inner attributes for blocks and expressions. Hence, rather than @cold x + y, one would write (@!cold x) + y. I actually prefer this in general, because it makes the precedence clear.

OK, so what are the options?

Using @ for attributes is popular. It is the use with macros that is controversial. Therefore, how I see it, there are three things on the table:

  1. Use @foo for attributes, keep foo! for macros (status quo-ish).
  2. Use @foo for both attributes and macros (the proposal).
  3. Use @[foo] for attributes and @foo for macros (a compromise).

Option 1 is roughly the status quo, but moving from #[foo] to @foo for attributes (this seemed to be universally popular). The obvious downside is that we lose ! forever and we also miss an opportunity to unify attribute and macro syntax. We can still adopt the model where decorators and macros are interoperable, but it will be a little more strange, since they look very different.

The advantages of Option 2 are what I’ve been talking about this whole time. The most significant disadvantage is that adding a semicolon can change the interpretation of @foo() in a surprising way, particularly at the top-level.

Option 3 offers most of the advantages of Option 2, while retaining a clear syntactic distinction between attributes and macro usage. The main downside is that @deriving(Eq) and @inline follow the precedent of other languages more closely and arguably look cleaner than @[deriving(Eq)] and @[inline].

What to do?

Currently I personally lean towards options 2 or 3. I am not happy with Option 1 both because I think we should reserve ! and because I think we should move attributes and macros closer together, both in syntax and in deeper semantics.

Choosing between options 2 and 3 is difficult. It seems to boil down to whether you feel the potential ambiguities of @foo() outweigh the attractiveness of @inline vs @[inline]. I don’t personally have a strong feeling on this particular question. It’s hard to say how confusing the ambiguities will be in practice. I would be happier if placing or failing to place a semicolon at the right spot yielded a hard error.

So I guess I would summarize my current feeling as being happy with either Option 2, but with the proviso that it is an error to use a macro in decorator position unless it explicitly opts in, or Option 3, without that proviso. This seems to retain all the upsides and avoid the confusing ambiguities.

Appendix: A brief explanation of token trees

Token trees are the basis for our macro-rules macros. They are a variation on token streams in which tokens are basically uninterpreted except that matching delimeters ((), [], {}) are paired up. A macro-rules macro is then “just” a translation from a token tree to another token. This output token tree is then parsed as normal. Similarly, our parser is actually not defined over a stream of tokens but rather a token tree.

Our current implementation deviates from this ideal model in some respects. For one thing, macros take as input token trees with embedded asts, and the parser parses a stream of tokens with embedded token trees, rather than token trees themselves, but these details are not particularly relevant to this post. I also suspect we ought to move the implementation closer to the ideal model over time, but that’s the subject of another post.

Categorieën: Mozilla-nl planet

Ricky Rosario: SUMO Development Update 2012.1

do, 11/09/2014 - 01:29
SUMO Dev goes agile

Inspired by the MDN Dev team, the SUMO Dev team decided to try an agile-style planning process in 2012.

To be fair, we have always been pretty agile, but perhaps we were more on the cowboy side than the waterfall side. We planned our big features for the quarter and worked towards that. Along the way, we picked up (or were thrown) lots of other bugs based on the hot issue of the day or week, contributor requests, scratching our own itch, etc. These bugs ended up taking time away from the major features we set as goals and, in some cases, ended up delaying them. This new process should help us become more predictable.

Starting out by copying what MDN has been doing for some time now, we are doing two week sprints. We will continue to push out new code weekly for now, so it is kind of weird in that each sprint has two two milestones within it. We will continue to name the milestones by the date of the push (ie, "2012-01-24" for today's push) and we are naming sprints as YEAR.sprint_number (ie, "2012.1" was our first sprint). We hope to will be doing continuous deployment soon. At that point we will only have to track one milestone (the sprint) at a time. For more details on our process, check out our Support/SUMOdev Sprints wiki page.

2012.1 sprint

We just pushed the second half of our first sprint to production. Some data:

  • Closed Stories: 26
  • Closed Points: 34
  • Developer Days: 36
  • Velocity: .94 pts/day

Our major focus of this sprint was getting our Elastic Search implementation (we are in the process of switching from Sphinx) to the point where we can index and start rolling it out to users. After today's push, we will find out whether this is working properly. *fingers crossed* (UPDATE: we did hit an issue with the indexing.)

Other stuff we landed:

  • Initial support for the apps marketplace. Basically, a landing page and a question workflow that integrates with zendesk for 1:1 help.
  • KPI (Key Performance Indicator) Dashboard. We landed the first chart which displays % of solved questions (it has a math bug in it that will get fixed in the next push).
  • Some minor UI fixes and improvements.
2012.2 sprint

We are currently halfway through our second sprint. Our main goals with this sprint are to get Elastic Search out to 15% of our users and to add a bunch of new metrics charts to the KPI Dashboard.

In my opinion, this new planning process is going well so far. The product team has better insight into what the dev team is up to day to day. And the dev team has better sense about what the short term priorities are. Probably the most awesome thing about it is that we are collecting lots of great data. The part I have liked the least so far has been the actual planning sessions, I end up pretty tired after those. I think it just needs a little getting used to and it is only 1-2 hours every two weeks.


Categorieën: Mozilla-nl planet

Ricky Rosario: SUMO Development: 2012.3 and 2012.4 Update

do, 11/09/2014 - 01:29

Oops, I procrastinated forgot to post an update for 2012.3 and we are done with 2012.4 too now.

2012.3 sprint
  • Closed Stories: 26
  • Closed Points: 37 (3 aren't used in the velocity calculation as they were fixed by James and Kadir - Thanks!)
  • Developer Days: 28
  • Velocity: 1.21 pts/day

The 2012.3 sprint went very well. We accomplished most of the goals we set out to do. We rolled out Elastic Search to 50% of our users and had it going for several days. We fixed some of the blocker bugs and came up with a plan for reindexing without downtime. Everything was great until we decided to add some timers to the search view in order to compare times of the Elastic Search vs the Sphinx code path. As soon as we saw some data, we decided to shut down Elastic Search. Basically, the ES path was taking about 4X more time than the Sphinx path. Yikes! We got on that right away and started looking for improvements.

On the KPI Dashboard side, we landed 4 new charts as well as some other enhancements. The new charts show metrics for:

  • Search click-through rate
  • Number of active contributors to the English KB
  • Number of active contributors to the non-English KB
  • Number of active forum contributors

We did miss the goal of adding a chart for active Army of Awesome contributors, as it turned out to be more complicated than we initially thought. So that slipped to 2012.4.

2012.4 sprint
  • Closed Stories: 20
  • Closed Points: 24
  • Developer Days: 19
  • Velocity: 1.26 pts/day

The 2012.4 sprint was sad. It was the first sprint without ErikRose :-(. We initially planned to have TimW help us part time, but he ended up getting too busy with his other projects. We did miss some of our initial goals, but we did as good as we could.

The good news is that we improved the search performance with ES a bunch. It still isn't on par with Sphinx but it is good enough to where we went back to using it for 50% of the users. We have plans to make it faster, but for now it looks like the click-through rates on results are already higher than what we get with Sphinx. That makes us very happy :-D.

We added two new KPI dashboard charts: daily unique visitors and active Army of Awesome contributors. We also landed new themes for the new Aurora community discussion forums.

2012.5 sprint

This week we started working on the 2012.5 sprint. Our goals are:

  • Elastic Search: refactor search view to make it easier to do ES-specific changes.
  • Elastic Search: improve search view performance (get us closer to Sphinx).
  • Hide unanswered questions that are over 3 months old. They don't add any value, so there is no reason to show them to anybody or have them indexed by google and other search engines.
  • Branding and styling updates for Marketplace pages
  • KPI Dashboard: l10n chart
  • KPI Dashboard: Combine solved and responded charts

We are really hoping to be ready to start dialing up the Elastic Search flag to 100% by the time we are done with this sprint.

Categorieën: Mozilla-nl planet

Ricky Rosario: SUMO Development: 2012.2 Update

do, 11/09/2014 - 01:29

Yesterday we shipped the second half of the 2012.2 sprint. We ended up accomplishing most of our goals:

  • [Elastic Search] Perform full index in prod - DONE
  • [Elastic Search] Roll out to 15% of users - DONE
  • Add more metrics to KPI dashboard - INCOMPLETE (We landed 3 out of the 4 new graphs we wanted).

Not too bad. In addition to this, we made other nice improvements to the site:

Great progress for two weeks of work! Some data from the sprint:

  • Closed Stories: 30
  • Closed Points: 38
  • Developer Days: 35
  • Velocity: 1.08 pts/day
Onward to 2012.3

We are now a little over halfway into the 2012.3 sprint. Our goals are to roll out Elastic Search to 50% of users, be ready to roll out to 100% (fix all blockers) and add 5 new KPI metrics to the KPI dashboard. So far so good, although we keep finding new issues as we continue to roll out Elastic Search to more users. That deserves it's own blog post though.

Categorieën: Mozilla-nl planet

Ricky Rosario: Joined the Mozilla Web Team

do, 11/09/2014 - 01:29

After 3 great years at Razorfish, I decided to move on and joined Mozilla 2 weeks ago. I will be working remote, but I spent the first week in Mountain View doing new hire orientation, setting up my shiney new MBP i7, setting up development environments for zamboni (new addons site) and kitsune (new support site), and fixing some easy bugs to start getting familiar with the codebase.

So far, I am loving it. Some of my initial observations:

  • My coworkers are super smart and awesome.
  • The main communication channel is through IRC (even when people are sitting nearby in the office). This works out great for the remote peeps like myself.
  • We use git/github for the our branch -> work on bug/feature -> review -> commit workflow. I am loving the process and github helps a ton with their UI for commenting on code.
  • Continuous Integration is the nuts.
  • Automated functional testing ^^.
  • Writing open source software full-time, and getting paid? Unreal!

I am working on SUMO ( It is currently going through a rewrite from tiki wiki to django (kitsune project). Working full time with django is like a dream come true for me (a very nerdy dream :).

Anyway, it is very exciting to work for Mozilla serving over 400 million Firefox users. I am looking forward to this new chapter in my career!

Categorieën: Mozilla-nl planet

Ricky Rosario: dotjs: My first Firefox Add-on

do, 11/09/2014 - 01:29

Inspired by defunkt's dotjs Chrome extension, I finally decided to play with the new add-on sdk to port the concept to Firefox. dotjs executes JavaScript files in ~/.js based on their filename and the domain of the site you are visitng. For example, if you navigate to, dotjs will execute ~/.js/ It also loads in jQuery so you can use jQuery with in your scripts even if the site doesn't use jQuery (it is loaded with .noConflict so it doesn't interfere with any existing jQuery on the page).

You can get the add-on for Firefox 4 on AMO and it doesn't require a browser restart (woot!). The code is on github. Feedback and patches welcome!

Categorieën: Mozilla-nl planet

Ricky Rosario: (SUMO) +dev in 2013

do, 11/09/2014 - 01:29

This is my first and last blog post for 2013!

Whewww, 2013 has been another splendid year for SUMO and the SUMO/INPUT Engineering team. We did lose (and missed a ton) our manager, James Socol, early in the year and I took over the managerial duties for the team, but the core dev team stayed intact.

Some metrics

Here are some metrics about what our platform, team and community was up to in 2013:

  • Page views: 502,812,271
  • Visits: 255,122,331
  • Unique visits: 190,633,959
  • Questions asked: 33,482
  • Questions replied to: 31,746 (94.8%)
  • Questions solved: 9,048 (27%)
  • Replies to questions: 119,440
  • Support Forum contributors:
    1+ answers: 8,723
    2+ answers: 3,436
    3+ answers: 1,764
    5+ answers: 742
    10+ answers: 247
    25+ answers: 97
    50+ answers: 63
    100+ answers: 42
    250+ answers: 22
    500+ answers: 17
    1000+ answers: 11
    2500+ answers: 7
    5000+ answers: 3
    10000+ answers: 1 (20,057 answers by cor-el)
  • Army of Awesome tweets handled: 46,030
  • Army of Awesome contributors: 911
  • Knowledge Base (KB) Revisions: 16,561
    en-US KB Revisions: 2,975
    L10n KB Revisions: 13,586
  • Locales with activity: 55
  • en-US KB Contributors: 165
  • L10n KB Contributors: 607
  • KB Helpful votes: 4,214,528 (72.6%)
  • KB Unhelpful votes: 1,587,416 (27.4%)
More metrics

Willkg wrote a blog post with that contains a lot more metrics specific to our development (bugs filed, bugs resolved, commits, major projects, etc.). Go check it out!

I wanted to highlight a few things he mentioned:

In 2011, we had 19 people who contributed code changes.
In 2012, we had 23 people.
In 2013, we had 32 people.


Like 2011 and 2012, we resolved more bugs than we created in 2013. That's three years in a row! I've never seen that happen on a project I work on.


Input also had a great year in 2013. Check out willkg's blog post about it.


2013 was a great year for the SUMO platform. We finetuned the KB information architecture work we began in 2012 and simplified all of the landing pages (home, product, topic). In 2014, I am hoping we can make the Support Forum as awesome as the KB is today.

In addition to making the KB awesomer... The Support Forums now support more locales than just English. We now send HTML and localized emails! We added Open Badges! We switched to YouTube for videos. We improved search for locales. We made deployments better. We implemented persona (not enabled yet). We implementated escalation of questions to the helpdesk. We added lots of new and improved dashboards and tools for contributors and community managers. At the same time, we made lots of backend and infrastructure improvements that make the site more stable and resilient and our code more awesome.

As a testament to the awesomeness of the platform, new products have come to us to be their support platform. We are now the support site for Webmaker and will be adding Open Badges and Thunderbird early in 2014.

Thanks to the amazing awesome splendid dev team, the SUMO staff and the community for an awesome 2013!

Categorieën: Mozilla-nl planet

Christie Koehler: An Update from the MozillaWiki Team, including a report from Wikimania London

wo, 10/09/2014 - 21:29

Last week we pushed a major upgrade to MozillaWiki, one that was months in the making. This post discusses the process of that upgrade and also talks about work the MozillaWiki Team did while together in London for Wikimania.

Who is the MozillaWiki Team?

The MozillaWiki team (formerly called the Wiki Working Group) is a mix of paid and volunteer contributors working to improve MozillaWiki. It is facilitated by MozillaWiki module owner (myself) and peers Gordon P. Hemsley and Lyre Calliope (both volunteer contributors).

Results from MozillaWiki user survey informs current roadmap

This summer, OPW (GNOME Outreach Program for Women) intern Joelle conducted a survey of MozillaWiki users. Much of our current roadmap is informed by the results of this survey, including re-organizing the Main Page, making information easier to find, improving the mobile experience and making editing easier.

If you’re interested in the results of that survey, watch her presentation Improving the Gateway: Mozilla Wiki User Research.

Why upgrade Mozilla Wiki now?

The primary motivation for this upgrade was to make current the version of MediaWiki, the software that runs MozillaWiki. Running a relatively older version of MediaWiki (1.19) prevented us from utilizing newer, beneficial features as well as useful extensions that require current versions of MediaWiki.

The Mozilla Wiki now utilizes MediaWiki version 1.23, and you can read about key features and improvements here:

This upgrade was carried out in two steps. The first was to change the default skin to Vector, which we did at the beginning of August. The second was to upgrade the software and require all users to use the new skin. This work we did last week.

Why did we choose Vector and drop support for all other skins?

Creating and maintaining MediaWiki skins is a complex and time-consuming process.

The two previous custom skins used on MozillaWiki were Cavendish and GMO. Already these themes, particularly GMO, were missing features available to users in officially supported skins. Our planned upgrade would make this disparity in user experience even greater. While planning the upgrade, we determined it didn’t make sense to expend resources keeping these skins tested and up to date, nor did it make sense to continue to offer a broken user experience just to maintain familiarity.

We selected Vector as the default skin because it is the one supported by MediaWiki itself and is thereby guaranteed to be stable and fully-featured. MonoBook is another theme supported by MediaWiki and we have left that enabled and available to use for those users who want an alternative look and feel. (You can make this change on your preferences page.)

Report from Wikimania London

As I mentioned, the MozillaWiki team has been preparing for and planning for this upgrade for several months. A small group of us gathered in London this August to have dedicated time to work together together and learn about MediaWiki and how to best utilize it at Mozilla by attending Wikimania, the annual MediaWiki community conference

The group included an even mix of paid and volunteer contributors who had been regularly participating in MozillaWiki team activities: Lyre Calliope, Jennie Halperin, Joelle F, Gordon P. Hemsley, C Liang and myself.

We spent the first two days hacking on MozillaWiki and the other three attending conference sessions and hacking together in between.

Having this rare time together in one place allowed us to get a lot done in a relatively short period of time.

Tasks we accomplished include:

  • updated sidebar (only visible in Vector and MonoBook)
  • created and deployed a new Main Page
  • roadmap planning through 2015 q1
  • planned and tested an upgrade to MediaWiki 1.23
  • continued to work on category planning

During the Wikimania conference, we accomplished the following:

  • learned about upcoming changes in MediaWiki, such as the new search extension (elastic search)  and visual editor
  • generated ideas for engaging new contributors across Mozilla projects, via targeted campaigns and directed play
  • generated ideas for recognizing different kinds of contributions leveraging badges and other projects at Mozilla
  • increased awareness of the Mozilla Wiki in the larger wiki community
  • learned about ways to enable real-time collaboration on the wiki
  • invited a number of Wikimedians to join Mozilla via the Wiki Working Group, CBT, and other areas

All of this information and collaboration helped us create our current roadmap.

Improvements planned for rest of 2014

We’re really proud of the work we’ve done on the Mozilla Wiki so far, but we’ve no intention to slow down yet. Improvements we’re planning to roll out this year, include:

  • Bug 1051201 – Audit and adjust user rights (to restore important feature to users and make wiki easier to use)
  • Bug 1051189 – Install MobileFrontend extension (to provide a mobile-friendly interface)
  • Bug 915187 – Improve search
  • Bug 1051204 – Implement real-time collaborative editing
  • Bug 1051206 – Improve discussion and collaboration
  • Bug 1064994 – Improve page categorization
An invitation to Participate

We hope you’re liking our work on MozillaWiki so far! We invite all those who would like to contribute to the wiki to join our regular MozillaWiki team meetings which are every other Tuesday at 8:30am PT (15:30 UTC). Our next meeting is 16 September. Participation details.

Categorieën: Mozilla-nl planet

Jet Villegas: Protect Net Neutrality

wo, 10/09/2014 - 21:28

Doing my small part to support the efforts today (September 10, 2014)

Categorieën: Mozilla-nl planet

Monica Chew: Making decisions with limited data

wo, 10/09/2014 - 18:05
It is challenging but possible to make decisions with limited data. For example, take the rollout saga of public key pinning.

The first implementation of public key pinning included enforcing pinning on In retrospect, this was a bad decision because it broke the Addons Panel and generated pinning warnings 86% of the time. As it turns out, the pinset was missing some Verisign certificates used by, and the pinning enforcement on included subdomains. Having more data lets us avoid bad decisions.

To enable safer rollouts, we implemented a test mode for pinning. In test mode, pinning violations are counted but not enforced. With sufficient telemetry, it is possible to measure how badly sites would break without actually breaking the site.

Due to privacy restrictions in telemetry, we do not collect per-organization pinning violations except for Mozilla sites that are operationally critical to Firefox. This means that it is not possible to distinguish pinning violations for Google domains from Twitter domains, for example. I do not believe that collecting the aggregated number of pinning violations for sites on the Alexa top 10 list constitutes a privacy violation, but I look forward to the day when technologies such as RAPPOR make it easier to collect actionable data in a privacy-preserving way.

Fortunately for us, Chrome has already implemented pinning on many high-traffic sites. This is fantastic news, because it means we can import Chrome’s pin list in test mode with relatively high assurance that the pin list won’t break Firefox, since it is already in production in Chrome.

Given sufficient test mode telemetry, we can decide whether to enforce pins instead of just counting violations. If the pinning violation rate is sufficiently low, it is probably safe to promote the pinned domain from test mode to production mode. The screenshot below shows a 3 week period where we promoted and and Google domains to production, as well as expand coverage on Twitter to include all subdomains.

Because the current implementation of pinning in Firefox relies on built-in static pinsets and we are unable to count violations per-pinset, it is important to track changes to the pinset file in the dashboard. Fortunately HighStock supports event markers which somewhat alleviates this problem, and David Keeler also contributed some tooltip code to roughly associate dates with Mercurial revisions. Armed with the timeseries of pinning violation rates, event markers for dates that we promoted organizations to production mode (or high-traffic organizations like Dropbox were added in test mode due to a new import from Chromium) we can see whether pinning is working or not.

Telemetry is useful for forensics, but in our case, it is not useful for catching problems as they occur. This limitation is due to several difficulties, which I hope will be overcome by more generalized, comprehensive SSL error-reporting and HPKP:
  • Because pinsets are static and built-in, there is sometimes a 24-hour lag between making a change to a pinset and reaching the next Nightly build.
  • Telemetry information is only sent back once per day, so we are looking at a 2-day delay between making a change and receiving any data back at all.
  • Telemetry dashboards (as accessible from telemetry.js and need about a day to aggregate, which adds another day.
  • Update uptake rates are slow. The median time to update Nightly is around 3 days, getting to 80% takes 10 days or longer.
Due to these latency issues, pinning violation rates take at least a week to stabilize. Thankfully, telemetry is on by default in all pre-release channels as of Firefox 31, which gives us a lot more confidence that the pinning violation rates are representative.

Despite all the caveats and limitations, using these simple tools we were able to successfully roll out pinning pretty much all sites that we’ve attempted (including AMO, our unlucky canary) as of Firefox 34 and look forward to expanding coverage.

Thanks for reading, and don’t forget to update your Nightly if you love Mozilla! :)
Categorieën: Mozilla-nl planet

Kim Moir: Mozilla pushes - August 2014

wo, 10/09/2014 - 16:09
Here's August 2014's monthly analysis of the pushes to our Mozilla development trees.  You can load the data as an HTML page or as a json file.

It was another record breaking month.  No surprise here!

  • 13090 pushes
    • new record
  • 422 pushes/day (average)
    • new record
  • Highest number of pushes/day: 690 pushes on August 20.  This same day corresponded with our first day where we ran over 100,000 test jobs.
    • new record
  • 23.12 pushes/hour (average)

General Remarks
Both Try and Gaia-Try have about 36% each of the pushes.  The three integration repositories (fx-team, mozilla-inbound and b2g-inbound) account around 21% of all the pushes.

August 2014 was the month with most pushes (13,090  pushes)
August 2014 has the highest pushes/day average with 620 pushes/day
July 2014 has the highest average of "pushes-per-hour" with 23.51 pushes/hour
August 20, 2014 had the highest number of pushes in one day with 690 pushes

Categorieën: Mozilla-nl planet

Prashish Rajbhandari: The Plan – After MozDrive

wo, 10/09/2014 - 06:33


“You should install a GPS tracking app in your phone so that we can track your location anytime.”

“If we don’t see your social media update every hour, we’re going to call and find you.”

“When you go through this route, don’t go wandering around except the highway. Just drive, don’t stop.”

“You better be in one piece at the end of the 25 days. We need you here!”

It was my last day as an intern in the Silicon Valley. My colleagues and supervisor jokingly threw comments and suggestions at me while I was debugging my final piece of production code before I leave. All my luggage and equipments were packed and stationed in the office so that I could directly go to the airport to catch my flight. My schedule was so tight that I had to drive out the day I landed in Cincinnati. There was no time to relax nor meet friends after I got home. I had to immediately check-in with my friend who was suppose to drive out with me, pack my remaining things, make sure we have everything for the journey (food, medicines and utilities) and head out. The fatigue after the 12-hour flight along with the timezone difference was the last thing on my mind. To understand the scenario, let me take you back a bit.

It had been 23 hours since I took a short nap, let alone good sleep. I was participating in an intern hackathon in LinkedIn HQ (probably one of the best hackathons that I’ve been to). It was 3 am in the morning and I was so caffeinated to a point that I was lost in my own code base. As I was working to fix a nagging problem, I received a notification in my inbox. You know those situation when you are feeling so helpless that you wander off as an legitimate excuse in the slightest opportunity in front of you. Yep, that was one of them. I even started opening some unread “Deal of the Week’ emails to reset my brain.

The message read -

“This is approved by the council. We really can’t wait to see the first report from this. : D Good luck : )”

As my brain was still trying to process the email because of how sleep deprived I was, I got another notification.

“Hi Prashish, Please document your trip thoroughly. We are very excited and waiting to see all your videos, pictures, blogposts and reports. : D”


It had been little over a week since I sent my proposal to the Mozilla Reps Council and to be honest, I didn’t have much hope for my mega-drive to get approved. I had to stay calm, control my emotions and send out a ‘Thanks!’ email sounding happy and excited. I did that. Before telling this to all my friends and Mozillians who had been constantly supporting me, I had to finish my project in the hackathon. It was a test of control. I shut down the emotions and continued working on the project without sleep for another 17 hours. Even after the presentations was done and the event was officially over, I didn’t want to think with my super-tired head. It was a test of patience. I wanted a sound sleep and then think of the super exciting journey that I would be taking from the month of August.  I couch surfed at a nearby friend’s house in Santa Clara and woke up fresh after a full 12-hour uninterrupted sleep. I passed all my tests. It was the beginning of couch surfing and what was to come in the next one month.

The next few days kept me super busy as I planned and launched the official website, social networking profiles (Twitter, Facebook) and a Q/A page. As I was working on the MozDrive website, I asked several Mozillians for suggestions and testimonials.

William Reynolds, Product Manager at Mozilla – “I’m excited about the Mozilla Awareness Drive. This is one of the most ambitious campaigns organized by a Mozillian. There’s nothing like visiting Mozilla and Firefox fans and having casual chats with them.”

Sayak  Sarkar, Mozilla Reps Super Mentor  – “I think that this is perhaps one of the most ambitious yet promising initiatives towards spreading the Mozilla mission and awareness about the open web since the Firefox Crop Circle initiative. This initiative speaks out a great lot about how passionate Mozillians are towards the project and how much they are inspired towards contributing towards a common goal of a Free and Open Web.”

The testimonials by Sayak and William really caught my eyes as both of them used the phrase – ‘one of the most ambitious’. To be honest, I didn’t realize the scale of this project until the very last moment. It isn’t that I didn’t understand the project but the desire to do something meaningful for the Mozilla community made the whole planning process look very straightforward. You see, it had been little less than a year since I came to the United States as a graduate student. Back in Kathmandu, Nepal, I would be attending/organizing Mozilla related events in a regular basis; be it orientations, hackathons or meet ups. That drastically changed after I stepped in the United States as I was adapting to the new environment and getting myself caught in the new world around me. To be fair, I did attend the Mozilla Festival in London and Mozilla Reps Meet up in Portland the same year. But, I felt I didn’t make a lot of impact that I would have liked to. In Nepal, there was a huge movement in Mozilla and Open Source that you could actually see the community growing and getting more active. That was something that I wanted to do here too.

The Mozilla Community is very close to my heart because everyone really cares about their work and how that impacts lives around the world. Every Mozillians that I meet are passionate about their work and the community. There is no ‘I’ but ‘We’ in our community. You don’t see a lot of these sort of things in the world we live in. And to be part of this, always makes me a proud Mozillian. I could have easily spent my 25-days break completing full seasons of TV series that I’ve always wanted to. Or if I wanted to be productive, work on a hobby project. Both of them sounded fun as I had spent months working on many products in a very competitive startup in the heart of Silicon Valley. But that’s not something Mozillians do. A Mozillian would spend his free time taking actions on how he/she could build communities together. A Mozillian would plan and work to make the web free and open. A Mozillian would create a movement. That’s what I wanted to do. I wanted to inspire thousands of Mozillians around the world to take actions on their dreams to make them a reality. That’s the reason I set out on this incredible journey to travel around the United States to spread the love about Mozilla and the Open Web.

To tell you the truth, I’m freaking scared of driving. But who isn’t? When there are cars zooming from every direction, the only thought in my head is reaching my destination safely. I never drove a car for more than 10 hours total in my life (which includes me sitting on the driver’s seat and being amazed by all the buttons in front of me). I never had a driving license in Nepal and I barely passed the maneuvering exam on the same day that I was set to fly for San Francisco (internship). That left me with a learner’s permit to drive with a legal driver next to me.

But that didn’t stop me from driving almost half the United States in less than a month. It didn’t stop me from gathering the courage to say ‘YES!’ to the most amazing adventure even though I had no prior experience. It didn’t stop me from taking that risk that would drastically change my life for good.

You might think I’m crazy.

Ask John – that guy who we found in Craigslist to rideshare with us to Los Angeles. He had traveled to almost all the US States and when I told him about our drive, he immediately responded –  ‘You(‘re) crazy man!’.

Or ask Laura – the lady who I met in Nelson-Atkins Museum of Art, Kansas City and had to convince her by showing MozDrive’s Facebook page after she rejected my approach saying – ‘I don’t buy this sh*t’.

Or ask my mom whom I had to convince 4 times everyday that everything will be alright and is under control.

Because driving 13,000 miles in 25 days which is around 8-10 hours everyday is not a joke in any sense. The body and mind could take so much that you needed a lot of self control and motivation throughout the journey for you not to burn out. Yes, there were times when I questioned the entire journey and why I was doing this. Yes, there were times where I wanted to chicken out half way through thinking people will forget about this. But, when you are on a journey which carried such powerful mission and values, that becomes your driving force. When you truly believe in a cause, your physical body will somehow find a way to make it happen and keep you moving forward.

The journey itself was immense where I had opportunities to meet people from all walks of life, culture and countries. I have so much stories to share that I don’t even know where to start. But I promise, I will. That’s why you are reading this. I want you to know what’s in store for everyone in the next 3-4 months. I’m not a writer by any means nor do I have any experience in professional writing. It took me two days just to think and come up this amateur 2,000 word chapter. But, I’m a strong believer of Growth Mindset, and I believe that I can eventually learn the art of expressing my thoughts and ideas through words. My final goal is to write at least 20 chapters of my experience during MozDrive. And to take it one step further – publish it as an ebook in future. That’s the dream!

It is impossible to accomplish a goal without taking actions on it. And this is my first step towards that goal. I know it will take a longer time, but I feel that it will be worth it at the end. And I do hope that you find a positive progress in my writing over time. By taking actions, I simply aim to inspire and awaken hearts of people to do something that they believe in.

If you are reading this – I thank you for taking time and interest in my next journey for MozDrive. Since, I am no writer, I’m looking for people who would be interested to proof-read and edit my future articles for MozDrive. Please send me a message or tweet if you have any suggestions, feedback or are interested in being part of this journey with me.

‘Til then.

Filed under: MozDrive, Mozilla Tagged: mozdrive, mozilla, mozrep
Categorieën: Mozilla-nl planet

Jorge Villalobos: Taller de Firefox OS en Panamá

wo, 10/09/2014 - 04:32

Me invitaron a dar una charla de desarrollo para apps en Firefox OS este fin de semana, en Ciudad de Panamá. El evento fue organizado por CascoStation, un coworking ubicado en un área muy interesante de la ciudad. Harold de CascoStation hizo un trabajo excepcional para asegurarse que todo saliera bien y todos estuviéramos muy cómodos.

El taller fue similar a los que he dado en el pasado, con algunas mejoras gracias a las lecciones aprendidas. La charla introductoria se puede encontrar aquí: Introducción a Firefox OS. Algunas de las páginas no tienen mucho sentido sin la charla, pero los vínculos son útiles para empezar a trabajar con Firefox OS.

La asistencia fue buena, alrededor de 20 personas. Lo más importante es que la mayoría tuvo suficiente interés para jugar un rato con Firefox OS durante el taller. Tomamos una foto grupal, pero ya varios se habían ido.

Foto de grupo al final

También nos hicieron una nota en El Espectador de Panamá, donde se puede apreciar un poco el ambiente del taller.

Una sorpresa muy grata es que en CascoStation trabaja un artista 3D muy habilidoso, que además aplica sus talentos para crear impresiones 3D con un nivel de detalle espectacular. Él nos creó una figura de Firefox OS que no podría haber quedado mejor.

Modelo de la figura de Firefox OS Figura de Firefox OS

Espero que podamos ver más de estos en el futuro :).

Por último, pude conocer a algunos de los miembros de la nueva comunidad de Mozilla Panamá (y en Facebook). Pudimos hablar sobre los lanzamientos en América Central y los retos que tenemos adelante. Esperamos tener noticias de Costa Rica muy pronto.

La experiencia estuvo excelente, y esperamos ver de nuevo a nuestros amigos panameños en unas semanas para el Encuentro Centroamericano de Software Libre 2014.

Categorieën: Mozilla-nl planet

Mike Shal: Build System Partial Updates

wo, 10/09/2014 - 02:00
There is a fairly long dev-platform thread about partial updates - specifically, running './mach build subdirectory'. In this post, we'll compare how this is handled in make-based systems, as well as in tup.
Categorieën: Mozilla-nl planet

Michael Kaply: Changes to CCK2 Support

di, 09/09/2014 - 23:38

When I originally came up my CCK2 support options, I thought that folks would use the basic support option as a way to simply show their support for the CCK2. It hasn't really turned out that way, and so effective immediately, I will no longer offer the CCK2 basic support option. I'm simply not getting enough business at that level to warrant the overhead.

Anyone that has already purchased basic support or is in the process of purchasing it will still receive the rest of their 1 year term. After that expires, they will have to choose the free or premium support option.

As far as premium support goes, I'm not planning any changes to that right now, but honestly it hasn't been as successful as I thought it would. I know there are hundreds of companies using the CCK and CCK2, so I'm surprised how few are willing to pay for your support. If anyone has any suggestions on things I can do to encourage folks make the support more appealing, I would appreciate them.

I'm continuing to update the CCK2, so make sure you grab the latest version (2.0.12). There were some update issues, so not everybody was updated.

Categorieën: Mozilla-nl planet

Christian Heilmann: How to draft a speaker information email

di, 09/09/2014 - 12:21

I just had a real happy moment when I got an email from a conference organiser telling me all they need from me and all I need to know in a simple email:

Hi Christian.
I hope you are doing fine.
Your talk “$title” is scheduled for $date at 9:45am (it’s a 40 min talk, plus 5 for Q&A). This is the link to your slot.
$conference will be hosted at $place, $address (map).
Please, send me some options of flights and I will book one for you. I may need your passport number.
We will organize a (free) dinner for all speakers the night before, so you should arrive at least on $dinnerdate.
We will book a room for you for the following nights: $dates. The hotel is the $hotel **** .
Please remember to bring your laptop, charger and A/C adapter. In Spain we use Plug Type C, and you shouldn’t need any current transformer for your laptop.
There will be reinforced WiFi at the event and a separate segment for speakers, but please be prepared to deliver your presentation without access to the Internet, just in case. Remember to include any fonts or alternatively use a PDF version.
We are providing our speakers with a template that can be used for your talk, but feel free to use your own format if you have one.
Your talk may be recorded and shared later in our Youtube channel. We understand to be authorized to do so, unless you say otherwise.
Looking forward to hearing from you!

This is excellent, and a great blueprint to re-use. Well done, codemotion.

I have a similar way to tell conference organisers all I expect and give them the things they need with my conference organiser cheatsheet.

Categorieën: Mozilla-nl planet

Nick Thomas: ZNC and Mozilla IRC

di, 09/09/2014 - 12:19

ZNC is great for having a persistent IRC connection, but it’s not so great when the IRC server or network has a blip. Then you can end up failing to rejoin with

nthomas (…) has joined #releng nthomas has left … (Max SendQ exceeded)

over and over again.

The way to fix this is to limit the number of channels ZNC can connect to simultaneously. In the Web UI, you change ‘Max Joins’ preference to something like 5. In the config file use ‘MaxJoins = 5′ in a <User foo> block.

Categorieën: Mozilla-nl planet