MozTrap is what's called a "test case management system". Basically, software QA people need a structure and pattern to their testing. What to test, what versions to test on and what hardware/operatting system etc all is part of a "test suite". That's what MozTrap manages.

So this project was built by Mozilla's automation and tools team. It is currently not an actively developed project. Not because it's not needed or used but because it basically maps all the features we need. A large part of the code base was originally written by a personal friend of mine who I respect wholeheartedly; Carl Meyer of Django/pip/virtualenv/etc fame. I'm grateful for the awesome documentation he left behind amongst many other things.

Together with the team we sat down and listed all the biggest pain points as of today. Basically, the number one thing is speed. Pages load too slowly. Normally when web developers worry themselves with web performance it's a matter of shaving milliseconds off a page where a clients perception equals lost or gained profits. Here's not a problem of milliseconds but a problem of seconds. After some quick poking around on the production site and looking at some code the conclusion is simple: The site is so darn slow because the HTML sent from the server is way too MASSIVE. And baked into that is a mixture of the poor web server having to produce a massive HTML blob and it being sent over the wire.

One test run I made said it took 14 seconds to render a certain page.

Why is it so slow?

So how did this happen and why is it not Carl's fault? :) The reason it happened was because of the underestimated number of options added to the advanced filtering drop-downs. On a local dev version you never notice these things because you set up some options, for example tags, and the drop-down never gets larger than 10-20 options. For example, the "Creator" drop-down today has 1,664 different choices.

If you take all those choices and turn thing into a HTML like this: Adam\nBram... etc. you get 66Kb of just HTML. However, MozTrap doesn't work like that. Instead it uses pretty drop-downs that don't look like regular HTML drop-downs. See for yourself; go to https://moztrap.mozilla.org/results/runs/ and click the "Advanced Filtering" button.
So, that means that the HTML for each option instead looks like this:

span> class="filter-item">
  span> name="filter-creator" data-name="creator" value="1" id="id-filter-creator-1" class="check" type="checkbox">
  span> class="onoff">
    span> for="id-filter-creator-1" class="onoffswitch">Adam
                span> class="pinswitch">
    span> class="content" title="creator: Adam">Adam
  

Now you get 620Kb of just HTML just for the "Creators" field. Granted, that is the biggest field of all the drop-downs but lots of them are massive.

So, this makes the page weigh a total of about 1.1Mb just for the HTML. Not only is it a lot of work for the (Django) server to generate this but it's also a heck of a lot of data to send across the Internet on every page request.

So what was the solution?

An ideal solution would have been a significant re-write whereby much of the values of the page gets rewritten as later AJAX calls. I.e. load a skeleton that loads superfast, and then load some AJAX in the background. That AJAX could potentially be cached in the browser with localStorage or something so that you get something to show very quickly whilst you wait for the AJAX request to complete. But this would have been too big a change and the way the filtering works on these pages, you actually need all the options in the drop-downs on immediate load because of the way "pinned filters" work.

So the solution was to replace all the repeated HTML chunks with 1 JSON string and then a piece of Javascript template rendering. So, in the Django template code instead of:

{% for field in filters %}
  {% include "lists/_filter_group.html" with advanced=1 prefix="filter" pinable=1 %}
{% endfor %}

We now replace this with:

span>id="filter_group" type="text/html">
span> class="filter-group {{ field.cls }}" data-name="{{ field.key }}">
  span> class="category-title">
    {{ _field_name_lower }}
    {{# field.switchable }}
    ...

What that basically is is some Mustache code that I use to generate the HTML DOM nodes and insert into the page after load.

In conclusion

So basically nothing changes. Nothing of the Django view had to change. Visually there's no difference and the same actual user data is sent from the server to the client but just packed in a more optimal way.

There are multiple pages where these massive "Advanced Filtering" options exist but on one page I measured the whole page went from weighing 1.1Mb down to 132Kb.

http://www.peterbe.com/plog/optimizing-moztrap

I’m in one of those ‘need to get back to blogging’ modes. Thinking about a lot of things. Feeling too busy to blog. Waiting until I have the perfect thing to say. Which is always a bad sign.

So, to get the juices flowing, I just decided to make a list of things I’m thinking about. Here it is:

1. Connecting open mobile <-> local content <-> web literacy — we we need to make progress on all three of these things at once if we want the web to be a serious player for the next few billion internet users. I’m working up a project on this topic with Ben, David and others.

2. Building a web literacy mentor community that scales — I’m excited about Maker Party, but also worried we’ll see post-campaign drop off again this year. We need a more systematic mentor program that grows, gets better and keeps people engaged 365/days a year. I’m helping Michelle and Brett think about this.

3. Figuring out the connection between an open internet and a fair internet. This a tricky. We assume an open internet will unlock opportunity for the billions of people coming online over the next few years. But it could just as easily lead to digital sweatshops. My new friends Chris and Brooke got me thinking about this in April. And I haven’t stopped thinking about it since.

4. Finding the right balance between clear goals, working across teams and distributed leadership. If I’m honest, we’ve struggled with these things at MoFo for the last 18 months or so. Our recent all hands in San Francisco felt like a breakthrough: focused, problem-solvey, fast moving. I’m thinking alot about how to keep this feeling. Working with Gunner and a bunch of other people on this.

5. Pushing on the Hive Lab concept. Some of the best Webmaker ideas — and much of our new Webmaker ‘textbook’ — come from the educators, designers and programmers we work with in Hives. However, we haven’t really figured out a way to systematically support and invest in this ‘lab’ side of Hive. I’ve been working with Claw and others to see how we can do more here.

6. Raising money. I’m always thinking about this, so it’s on my list. Right now, I’m thinking about major gifts, which is an area we’ve never cracked. IMHO, breaking through in this area is critical if we want to build Mozilla into a 100 year org that withstand the ups and downs of the market. I’m starting to talk to Geoff about this. Also, looking for outside people to help.

7. Linking Maker Party and net neutrality. Alot of the issues that Mozilla cares about are hard for people to get their heads around — net neutrality, DRM, etc. We should be able to use our web literacy work to help with this. I’ve been talking to Dave, Amira and others about building a ‘net neutrality teach-in’ campaign into Maker Party as an experiment in making this web literacy <-> big-hairy-internet-issue link.

8. Talking about LEGO some more. Specifically: how the LEGO Movie has a bunch of corny-but-useful metaphors for how screwed the Internet is right now. And how we can’t rely on a single here (e.g. Mozilla) to save the day. Spoiler: I’m going to use some LEGO Movie clips in my Knight Civic Media Conference talk later this month.

Random. I know. But these are places my brain is right now. A little scattered. But all feels juicy, good, important. Will write in more depth on some of these things soon.

http://commonspace.wordpress.com/2014/06/03/things/

Today the Mozilla MathML team released a new version of TeXZilla. You can download a release package or install it with npm. We fixed a few bugs, but there are known issues due to errors in the unicode.xml file of XML Entity Definitions for Characters or inherited from the itex2MML grammar that does not make it ready for version 1.0. The main improvements in this new release are enhancements to the public API and to the command line interface.

Stream filter

TeXZilla can now be used as a stream filter. Each TeX expressions delimited by the classical $ ... $, $$ ... $$, \[ ... \] and \( ... \) will be converted into inline or display MathML. Outside these delimiters, you can use \$ and \\ as escaped characters. We offer three ways to apply that stream filter:

• From the command line, in a UNIX pipeline:

  cat foo-tex.html | phantomjs TeXZilla.js streamfilter > foo-mathml.html

  echo "This is a **Markdown** document with a *math formula*: $ z = \\sqrt{x^2 + y^2} $" | markdown | nodejs TeXZilla.js streamfilter | sed '1s/^/\n\n/'

  (note: this is not yet supported by slimerjs)

• Using the TeXZilla.filterString(aString) function, for example TeXZilla.filterString("blah $x^2$ blah") will return the filtered string.

• Using the TeXZilla.filterElement(aElement) function. This one will browse recursively the descendants of the DOM element aElement and the stream filter will be applied to the text leaves.

By introducting these TeXZilla.filter* function, it becomes tempting to use TeXZilla the same way as MathJax, that is to process all the text nodes in your Web pages and to filter the TeX strings. This is not the intended goal of TeXZilla and it is strongly discouraged: not only the MathML content won't appear in crawlers (e.g. search engines or feed readers) but also browsing all the DOM elements and appending new ones can be very slow for large documents. Instead, it is recommend to filter your static Web page with commonJS TeXZilla.js streamfilter before publishing it or to use a server-side conversion for example using the Web server mode. There are situations where you do not have other choice, though. In that case try to reduce as much as possible the number of elements being processed (see the example in the next section). Of course, if you do not care about performance and MathML availibility outside your web site, you can just use MathJax.

New Safe and Itex-Identifier parsing modes

The most notable difference between TeXZilla and itex2MML is the handling of some expressions like $xy$ or $Func$. By default, TeXZilla interprets this as individual MathML identifiers xy (so that as in LaTeX, they will render in italic) while itex2MML interprets this as a single indentifier Func. It is now possible to configure TeXZilla to align with itex2MML's behavior. To do that, use TeXZilla.setItexIdentifierMode or pass the appropriate boolean to the command line. Consecutive non-basic letters (like Greek or Arabic) are still treated as individual tokens. With that change, we hope that TeXZilla could be used to parse all the commands supported by itex2MML into an equivalent output. Together with the command line stream filter, this should allow to recover all the nice itex2MML features.

Similarly, a safe mode is now available and can be enabled with TeXZilla.setSafeMode or by passing the appropriate boolean to the command line. This mode will forbid commands that could be used for XSS injections like \href. With that mode and the new TeXZilla.filterElement function, I'm now able to remove MathJax's use from my blog (users of browsers without good MathML support can still enable it or choose the lighter mathml.css stylesheet). MathJax was a bit overkill for my blog since I'm only parsing visitor comments. To illustrate how the setSafeMode and filterString functions can be used, I now just have to do

// Process TeX fragments in blog comments and comment preview.
window.addEventListener("DOMContentLoaded", function() {
  TeXZilla.setSafeMode(true);
  var toProcess =
    document.querySelectorAll("#comments > dl > dd, #comment-form dd.comment-preview");
  for (var i = 0; i < toProcess.length; i++) {
    TeXZilla.filterElement(toProcess[i]);
  }
});

Inserting equations in a 2D/WebGL canvas

The new function TeXZilla.toImage has been introduced to convert a TeX fragment into a math HTML image with a base64-encoded src attribute. Contrary to other functions of the API, this one needs to do some work to determine the image size and perform the conversion, so it is unlikely to work as expected in a non-browser context. The goal is really only to have a convenient function to generate image of mathematical formulas and insert them into a canvas context to draw 2D or 3D scientific schemas. At the moment, this works well only in Gecko. For instance,

var image =
    TeXZilla.toImage("\\vec{F} = G \\frac{m_1 m_2}{r^2} \\mathbf{u}");
image.onload = function() {
    canvas.getContext("2d").drawImage(image,
        (canvas.width - image.width) / 2,
        (canvas.height - image.height) / 2);
}

will insert a mathematical formula in the middle of a 2D canvas. Similarly, you can insert a mathematical formula as a texture in a WebGL canvas. It is recommended to pass aRoundToPowerOfTwo=true to TeXZilla.toImage, so that the image will have dimensions that are power of two. Note that the mathematical formula will be automatically centered in the middle of the generated image. See this example for how to setup the formulas with three.js and make them always oriented in the direction of the camera.

Integration in Mozilla products

• The CKeditor editor plugin is now integrated in MDN, so you can click on the square root logo in the editor toolbar to insert mathematical formulas. By the way, the mathml.css is now used for browsers without MathML support. See for example the pages for acosh, atanh or CSS transform.

• The editor/ in comm-central now integrates a small input box to insert mathematical formulas, accessible from the Insert menu. This will be available in Thunderbird 31 and Seamonkey 2.28, so that you can write mathematics in your emails and in the WYSIWYG editors.

• Various FirefoxOS Web math apps have been written and use TeXZilla. Raniere is also working on a math keyboard for FirefoxOS as a GSoC project, which will allow to type mathematics faster on mobile devices.

http://www.maths-informatique-jeux.com/blog/frederic/?post/2014/06/03/TeXZilla-0.9.7-Released

Last week, the Policy, Legal and Business Development teams had a 2-day get-together, and one thing I came to understand much more clearly is something I think that many Mozillians need to take to heart: success is not inevitable.

For the first few years of Mozilla’s life, we didn’t have much success. Then, a combination of good code, good grassroots marketing, sleeping or absent competitors and favourable market conditions saw Firefox take off and reach a desktop market share north of 25%. That was five years ago, and we’ve been trying to hold on to it since. We haven’t entirely succeeded, but it might be easy to imagine that Firefox on the desktop will be around and relevant forever.

But working really hard, and knowing that what you are doing is the right thing for the world, are not enough by themselves to guarantee that you succeed. There’s no law of the universe which says that Google have to keep giving us a search deal on better (or even the same) terms, particularly if our market share falls. That may happen, or it may not. And there’s no law which says that Firefox OS has to be a success. If what we build isn’t the right thing, carriers will stop stocking and promoting Firefox OS phones, and the world will be left with a choice of Apple, Google or Microsoft.

Mozilla’s way of working has always been to get market share by making great products, and use that to make our voice heard. We aren’t an advocacy-only organization.

Back when we did Firefox, our future, and our ability to get that market share, was in our own hands. If we wrote great software, users could download and install it themselves, and that was it. No-one was stopping consumers from installing any software they wanted. No-one was stopping OEMs from shipping copies of Firefox with their machines. We didn’t have to worry about proprietary hardware. There were no web features which couldn’t be implemented in open source code.

In the new world, our future and our ability to gain market share are not entirely in our own hands. We need partnerships to reach consumers. Business partnerships involve giving someone something they want in return for something you want, and they mean that usually you don’t get everything you want, but have to compromise. The need to partner and the need to compromise are relatively new and difficult things for Mozilla. Such agreements often come with obligations – which, in its most general form, is the loss of the ability to choose exactly what we are going to do because we are constrained by our promises. As an organization, particularly as an engineering organization, we don’t like that.

But operators are only going to carry and promote Firefox OS phones if they think it’s in their best interests to do so. And consumers are only going to buy them if they think they are better for what they want to do than the alternatives. “Why this rather than Android?” is a question to which we need a good answer.

If we want Firefox OS to be a success, we need partners, and we need to provide what those partners want, while holding on to our principles. What they want may well not be “software for us”, or even “software for people we know”. And that means we need to listen to the people within Mozilla who talk to them and report back to us. That’s the Business Development team – who currently have a pretty low community profile. Perhaps that needs to change.

Success is not inevitable – but it is still possible, if we carry on producing software that succeeds in the market. But how we find out what that means has changed, and we as Mozilla need to make sure we adapt to that, and listen in the right places.

http://feedproxy.google.com/~r/HackingForChrist/~3/C1Vy6QcX0VA/

the following changes have been pushed to bugzilla.mozilla.org:

• [1003970] Tagging comments not shown in user activity
• [993939] Bugzilla::User::Setting::groups() should use memcached
• [1000917] Record last-visited time of bugs when logged in
• [1016273] Bugzilla whine emails missing change to From header made by bug 1010751

discuss these changes on mozilla.tools.bmo.

http://globau.wordpress.com/2014/06/03/happy-bmo-push-day-96/

I just got a new MacBook Pro. It’s the fifth one I’ve had since 2005, and as usual the hardware is gorgeous, and migrating from the old laptop was a breeze.

But there’s one thing that boggles my mind about the default system configuration…

…the firewall is off by default. It was off by default on my previous MacBook Pro too. (I have a short file describing the steps I took when migrating to the old laptop, and “Security & Privacy: turn on firewall(!)” was one.)

My wife bought a MacBook Air a couple of months and I just checked and the firewall is disabled on it, too.

I admit I am not a world-class expert on matters of network security. Is this totally insane and negligent, or is there something I’m missing?

https://blog.mozilla.org/nnethercote/2014/06/03/why-do-new-macbooks-ship-with-the-firewall-off-by-default/

http://gittup.org/blog/2014/06/8-clobber-builds-part-3---other-clobber-causes/

• 11711  pushes
• New record
• 378 pushes/day (average)
• New record
• Highest number of pushes/day: 613 pushes on May 29, 2014
• New record
• 22 pushes/hour (average)
• New record

May 2014 is a record setting month, 11711 pushes!

Note that Gaia-try was added in April and has quickly become a high volume branch

I changed the format of this pie chart this month.  It seemed to be previously based on several months data, but not all data from the previous year.  So I changed it to be only based on the data from the current month which seemed more logical.

http://relengofthenerds.blogspot.com/2014/06/mozilla-pushes-may-2014.html

On a recent Webmaker call, I learned about the proposal to have the Webmaker teams start operating on a regular schedule, which has been dubbed “heartbeat.” Each heartbeat lasts two weeks, and includes planning, retrospection, heads down working, a mid-point check in, and demos.

I dig this. I was a Scrum Master in my former life, and the heartbeat idea echoes Scrum, which I know to be a super effective tool for creating rhythm on a team.

In addition to the benefits/goals cited in the presentation, I would add that rhythm is also good for:

• syncing between teams
• increasing accountability and trust within a team
• ensuring continuous improvement
• increasing velocity/productivity
• improving morale

Here are some thoughts on how we might implement a heartbeat within the context of the Engagement team:

• Identify the right heartbeat duration. Does two weeks make sense for the highly responsive and externally-focused work we do?
• Incorporate planning into our team meeting. This might just mean making sure the answers to the question “what will get done this week?” are in bugzilla and/or on the workbench. I’ve found that planning works best when teams are operating from a shared, continually updated backlog of items. If you have this, “planning” can be very low effort: it’s simply pulling a set of items from the top of the backlog and labeling them with the upcoming heartbeat.
• Add demos to our routine. This could be part of the weekly team meeting, or perhaps could be done in an ad-hoc way. Creating the expectation that each part of the team will demo something during each heartbeat would lend even more intentionality to the planning.
• Incorporate retrospecting behaviors. This might mean a 10-minute debrief at the end of every heartbeat, either for the whole team, or perhaps divided into the different functional areas. It might mean building a virtual suggestion box for people to share ideas about how to improve our process, or cultivating a weekly “One thing I will do differently this week is…” habit. There are lots of ways to build a culture of action-oriented retrospection!

Curious to know what others think about adopting the heartbeat model for the Engagement team.

http://hannahgrams.com/2014/06/02/heartbeat-engagement-style/

We now have a reasonably organized Mozilla Foundation Metrics Wiki Hub Page Thing.

While my priority to date this year has been working out how MoFo teams count their contributors, I thought I should also take the time to open up this metrics work in a way that contributors can get involved, if that’s what takes their fancy. After all, contributor metrics are only as good as the systems they help us improve, and in turn the contributors they help us empower.

As with many good things in the world of open source, this includes a mailing list.

So here’s by blurb if you’d consider signing up:

The mofo-metrics mailing list:

“An open community mailing list for volunteers and staff interested in Mozilla Foundation Metrics. What are the numbers, graphs and other data points that can help the Mozilla Foundation to better promote openness, innovation and participation on the Internet? Sign up and help us answer that question.”

• Subscribe to the mofo-metrics mailing list and say hello here.
• Or check-out the wiki to see what we’re working on

I’m not 100% sure what contribution will look like in metrics-land, but I’m happy find out and to try and make this work.

http://feedproxy.google.com/~r/adamlofting/blog/~3/IrU_asW6Cpw/

to echo wolf’s post – “The End of Firebot – A New Beginning”, i’m the new maintainer of the irc bot firebot.

firebot provided an excellent service, and i’m happy to ensure firebot’s continued existence.

i’d like to thank wolf for running firebot for a decade, and for allowing me to take over.

http://globau.wordpress.com/2014/06/01/firebot-has-a-new-owner/

Some custom keybindings:

tmux:

# Shift Left/Right to switch windows in tmux
# without the tmux prefix
bind-key -n S-Left previous-window
bind-key -n S-Right next-window
# Ctrl-prefix-o to highlight and open URLs
# https://github.com/dequis/tmux-url-select
bind o run /home/paul/bin/tmux-url-select.pl

Mouse via keyboard:

# Because the new Thinkpad "clickpad"
# is a joke. Via xdotool & xbindkeys:
Win-arrow to move a window
Ctrl-Win-arrow to resize a window
Shift-Win-arrow to move mouse
F1 left click
F2 middle click
F3 right click

Vim:

" Just  to switch buffers
nmap  :bn
nmap  :bp
" scroll but don't change the cursor position on screen
nnoremap  j
nnoremap  k
" visual command line
nnoremap ; :
" quick move via 
nmap  (easymotion-s2)
" quick save in insert mode
imap zz :w

Firefox:

# Vim controls, via vimfx (I don't want the full-blown vimperator)
# https://addons.mozilla.org/firefox/addon/vimfx/
Ctrl-e / Ctrl-y to scroll
gg / G for home / end
Ctrl-O to highlight then open a link

Mutt:

# Archive one email
macro index a "s=archivesy"
# Archive whole thread
unset resolve \
   \
  set resolve \
   \
  =archivesy

http://paulrouget.com/e/keybindings

SSL & TLS

MIG

Risk management

Wait, a realtime patch and vulnerability dashboard using elasticsearch and kibana? Why yes! (note: still beta) pic.twitter.com/ab14kwBDnA

— Michael Henry (@neoCrimeLabs) May 30, 2014

Winter of Security

https://jve.linuxwall.info/blog/index.php?post/2014/05/31/One-year-at-Mozilla

Millions of people use Firefox for Android every day. It’s amazing to work on a product used by so many people. Unsurprisingly, some of those people send us feedback. We even have a simple system built into the application to make it easy to do. We have various systems to scan the feedback and look for trends. Sometimes, we even manually dig through the feedback for a given day. It takes time. There is a lot.

Your feedback is important and I thought I’d point out a few recent features and fixes that were directly influenced from feedback:

Help Menu
Some people have a hard time discovering features or were not aware Firefox supported some of the features they wanted. To make it easier to learn more about Firefox, we added a simple Help menu which directs you to SUMO, our online support system.

Managing Home Panels
Not everyone loves the Firefox Homepage (I do!), or more specifically, they don’t like some of the panels. We added a simple way for people to control the panels shown in Firefox’s Homepage. You can change the default panel. You can even hide all the panels. Use Settings > Customize > Home to get there.

Improve Top Sites
The Top Sites panel in the Homepage is used by many people. At the same time, other people find that the thumbnails can reveal a bit too much of their browsing to others. We recently added support for respecting sites that might not want to be snapshot into thumbnails. In those cases, the thumbnail is replaced with a favicon and a favicon-influenced background color. The Facebook and Twitter thumbnails show the effect below:

We also added the ability to remove thumbnails using the long-tap menu.

Manage Search Engines
People also like to be able to manage their search engines. They like to switch the default. They like to hide some of the built-in engines. They like to add new engines. We have a simple system for managing search engines. Use Settings > Customize > Search to get there.

Clear History
We have a lot of feedback from people who want to clear their browsing history quickly and easily. We are not sure if the Settings > Privacy > Clear private data method is too hard to find or too time consuming to use, but it’s apparent people need other methods. We added a quick access method at the bottom of the History panel in the Homepage.

We are also working on a Clear data on exit approach too.

Quickly Switch to a Newly Opened Tab
When you long-tap on a link in a webpage, you get a menu that allows you to Open in New Tab or Open in New Private Tab. Both of those open the new tab in the background. Feedback indicates the some people really want to switch to the new tab. We already show an Android toast to let you know the tab was opened. Now we add a button to the toast allowing you to quickly switch to the tab too.

Undo Closing a Tab
Closing tabs can be awkward for people. Sometimes the [x] is too easy to hit by mistake or swiping to close is unexpected. In any case, we added the ability to undo closing a tab. Again, we use a button toast.

Offer to Setup Sync from Tabs Tray
We feel that syncing your desktop and mobile browsing data makes browsing on mobile devices much easier. Figuring out how to setup the Sync feature in Firefox might not be obvious. We added a simple banner to the Homepage to let you know the feature exists. We also added a setup entry point in the Sync area of the Tabs Tray.

We’ll continue to make changes based on your feedback, so keep sending it to us. Thanks for using Firefox for Android!

http://starkravingfinkle.org/blog/2014/05/firefox-for-android-your-feedback-matters/

Planet Mozilla viewers – you can watch this video on YouTube.

As part of all the work we’ve done letting people know what’s great about the new Firefox, we started running a campaign on the default Firefox start page last week. The first piece was about bookmarks – this week it’s customization. I love this Space Invaders animation and the page it links to. It’s fun, it’s engaging, it gives you enough detail to be truly helpful and it links to the full documentation on the support site.

https://blog.mozilla.org/verdi/427/i-love-this-education-piece-on-the-firefox-home-page/

Major highlights:

• Nick landed a big patch to Balrog (our new update server) that has unblocked the remaining work to move Beta users over to it.
• I moved our Flame builds over to Balrog, which is a huge step towards killing update.boot2gecko.org.
• Kim disabled many Android 2.2 tests on trunk branches on Tegras since these now run on 2.3 emulators. This should help reduce the load on our overburdened Tegra pool and is a first step toward deprecating this hardware completely.
• Rail brought up our first DNS-less AWS instances. These new instances take jobs more quickly than the older ones, and it’s much easier for us to add more to the pool.
• Massimo moved our ccache for AWS machines onto SSDs. This should result in a small improvement to build times.
• Aki killed the now-unused b2g18 (1.1) branches.

Completed work (resolution is ‘FIXED’):

• Balrog: Backend
• Requesting data of non-existent release yields a 500 error
• tracebacks on versions like “3.6.3plugin1''
• Buildduty
• Install loopback audio/video drivers on Linux test slaves
• Completed builds not appearing on TBPL
• Failure “TypeError: request() got an unexpected keyword argument ‘config’” on amazon dnsless spot instances
• General Automation
• hamachi device builds submitting bad urls to balrog
• Make it easier to run b2g_desktop_automation.py
• tons of UnauthorizedLogin errors on build/try masters
• [Flame] Please update the blobs to use blobs from 10G-2
• Tarako build for 5/28 is busted due to no rule to make target error.
• [Flame] Please update the blobs to use blobs from 10F-3
• Delay in Update availability (Aurora and Nightly)
• nexus 4 builds need to upload mars publicly
• Put ccache on SSDs
• ESR24 trying to run OSX 10.8 Cpp unit tests
• Schedule mochitest-oop against linux64_gecko on trunk branches
• /builds/slave is read only for cltbld
• Stop running cppunit and jittest on OS X 10.8 on all branches
• include device in fota mar filenames
• Loan Requests
• Connect a linux and mac slave to dev-master1:8950 for pkewisch
• Other
• Upgrade ASan Clang in Q1
• Platform Support
• Releng Config/Automation support of staging run of scl1->scl3 move
• New spot test images don’t have v4l2loopback configured
• disable selected tests on tegras
• Build make 3.82
• Create a Windows-native alternate to msys rm.exe to avoid common problems deleting files
• Release Automation
• Don’t use hardcoded hg.mozilla.org in release-runner.py
• release automation can’t update balrog blobs during the update step
• Repos and Hooks
• Create post-push hook to print cset url for QA repositories on hg.mozilla.org
• Tools
• kill b2g18 + b2g18_v1_1_0_hd

In progress work (unresolved and not assigned to nobody):

• Balrog: Backend
• Support new attributes for update.xml in Balrog
• add support for “isOSUpdate” attribute
• Buildduty
• Reconfigs should be automatic, and scheduled via a cron job
• [tracking] Eliminate buildduty
• General Automation
• Run Android 2.3 tests against armv6 builds, on Ash only
• Figure out the correct path setup and mozconfigs for automation-driven MSVC2013 builds
• Triggering arbitrary jobs gets branch wrong
• Create mozilla-esr31 branch
• [tracker] run Android 2.3 test jobs on EC2
• [Meta] Fix + unhide broken testsuites or else turn them off to save capacity
• Use properties to handle chunking
• switch b2g builds to use aus4.mozilla.org as their update server
• [Dolphin] Create Dolphin builds for 1.4
• Remove the need to create Puppet changes for BuildSlaves*.py.erb, production_config.py and production-master.json
• Tracking bug for 09-jun-2014 migration work
• Schedule Marionette tests on Windows on cedar
• Please add non-unified builds to mozilla-central
• kill b2g26_v1_2 on june 9 merge day
• Clean up b2g names in our configs
• revamp b2g upload configs
• Schedule Mn tests on opt Linux builds on cedar
• FlatFish: Integrate boot.img and recovery.img into the build system
• Add –disable-mock option to b2g_build.py
• Don’t require puppet or DNS to launch new instances
• Start doing mulet builds
• create in-tree CA pinning preload list
• Add support for webapprt-test-chrome test jobs & enable them per push on Cedar
• Loan Requests
• Loan :kmoir talos-linux64-ix-005
• Slave loan request for a t-mavericks-r5 machine
• Slave loan request for a bld-linux64-ec2 vm
• Other
• [tracking] infrastructure improvements
• Platform Support
• scl1 Move Train A releng config Work
• [tracker] Stop testing on tegras
• evaluate mac cloud options
• cancelled 2.3 mochitest jobs put ix slaves into weird state (and so need rebooting)
• FHR on Android should not be attempting to connect to the internet in automation jobs
• Windows slaves often get permission denied errors while rm’ing files
• Run unittests/talos on OS X 10.9 Mavericks
• Deploy hg.m.o/build/buildbot production-0.8 to buildslaves to pick up bug 961075
• Update version of pip installed on automation machines from 0.8.2 to 1.5.4+
• Add cloud-init to our base AMIs
• Release Automation
• release l10n repacks failed due to failed “rm”
• Releases
• tracking bug for build and release of Firefox and Fennec 31.0
• tracking bug for build and release of Firefox 24.7.0 ESR
• tracking bug for build and release of thunderbird 31.0
• tracking bug for build and release of Firefox 31.0 ESR
• tracking bug for build and release of Firefox and Fennec 30.0
• Modify AOL Repack Configuration
• Repos and Hooks
• Need branches of mozilla-b2g/codeaurora_kernel_msm for mako/hammerhead
• Request for a new repository in /gaia-l10n: mai
• [tracker] hg.mozilla.org user repository issues
• Fix missing trailing slashes for repositories in push_printurls.py
• Tools
• vcs-sync needs to populate mapper db once it’s live
• End-to-end reconfig should also update tools version on foopies
• Update trychooser for Android 2.3
• implement “disable” action in slaveapi
• Transplant tool (Hg to Hg) for sheriffs
• Please add treeherder to allowed origins response headers for BuildAPI self-serve
• db-based mapper on web cluster
• AWS Sanity Check lies about how long an instance was shut down for…

http://hearsum.ca/blog/this-week-in-mozilla-releng-may-30th-2014/

One of Mozilla’s goals for this year is to increase the number of active contributors by 10x. That means that many new people will be joining the community and we want to make sure they have a positive experience.

A few teams have contributor agreements that provide details about what it means to volunteer in that specific area, but there’s never been information that covers contributors in general.

To help new contributors understand more about what they’re getting involved with, we’ve drafted a new volunteer agreement. I wanted to share the text of that and talk about how we would make this available.

First though, I’d like to be clear about a couple of points:

• This is not intended to be a document that people will sign.
• This is not something that applies to existing contributors, just to new people who are joining the community.

After sharing the text of this here, on the Governance list and at an upcoming Monday project call, we’d like to add this text as a new page on http://www.mozilla.org.

We would then link to that from the Get Involved page, the entry point for most new contributors. We would add this to the existing opt-in on the form that references Mozilla’s Privacy Policy.

Please take a look at the text below and share your thoughts on that and on how we would make this available to new contributors.

————————-

DRAFT Volunteer Agreement

Welcome to Mozilla! We’re pleased that you will be working with us to volunteer your expertise, knowledge, and skills to our Project.

Before we begin, there are some basic terms you should be aware of and agree to. The following is an agreement between you and Mozilla that describes your volunteer work with the Project:

1. You or Mozilla may end this Agreement at any time for any reason on immediate notice. If you wish to end the Agreement, simply email a Mozilla staff member to let us know.

2. As a volunteer for our Project, you will be working with Mozilla staff, employees and other volunteers.

3. We have policies at Mozilla to protect the Project and you. While working with us, we want you to be creative and help us to grow the Project, while observing the following rules:

a. As a volunteer, you cannot bind Mozilla to any agreements or sign any agreements on behalf of Mozilla, but you can introduce Mozilla to different ideas, processes and ways of doing things;

b. You are not an employee or contractor of Mozilla and should not represent yourself as such;

c. You cannot engage in any activities that violate the laws of your locale, Mozilla’s policies, or the rights of any group or individual;

d. You agree to behave in a professional and respectable manner when acting as a Mozilla volunteer. Mozilla’s Participation Guidelines can be found at http://www.mozilla.org/en-US/about/governance/policies/participation/;

e. It’s definitely okay to talk about your contributions to Mozilla, but you should not use Mozilla’s logo or trademarks without Mozilla’s prior written consent. Mozilla’s trademark policy can be found at https://www.mozilla.org/en-US/foundation/trademarks/policy/; and

f. This Agreement is about you and only you. You may not transfer or give this to any other person or group.

g. If you violate any of these rules, Mozilla has the right to end this agreement and your volunteer activities.

http://davidwboswell.wordpress.com/2014/05/30/creating-a-volunteer-agreement/

Dve t'emer zapomenut'e fotky z lokace jizne od Prahy, focen'e loni v l'ete v noci z 16. na 17. cervna. Velmi kr'atk'a noc, slunce definitivne zapadlo snad az pred jeden'actou a po druh'e uz zase zacalo sv'itat. Zato divok'ych psu a prasat v okoln'i vysok'e tr'ave bylo pozehnane

Horn'i fotografie je jen viditeln'e svetlo, doln'i m'a modr'y overlay v IR p'asmu nad 742nm. Kvalita je sice mizern'a, z'aklad je vzdy jen jedna fotografie, ale me se to l'ib'i.

Canon 30D, MC mod
Canon EF 35mm/F2
HEQ5, ustavena tentokr'at driftovou metodou
Astronomik CLS-CCD: 1x600s @ F4.0, ISO 1000
Astronomik ProPlanet IR 742: 1x300s @ F4.0, ISO 1000
0x Flat/Dark/Bias
Zpracov'an'i v CR a PS

http://www.janbambas.cz/ngc-7000-ngc-6974-ic-1318-a-okoli-ir/

“Oh no! Something has gone wrong” message is all what you get when you VNC to Gnome 3 in Fedora 20 on a box without any physical monitor attached to any of the video outputs with enabled autologin and screen sharing (vino).  There is an error in /var/log/messages ‘TypeError: this.primaryMonitor is undefined’ at /usr/share/gnome-shell/js/ui/layout.js:410.  I haven’t found a Fedora bug open for this.

You cannot also simply configure e.g. tiger-vnc because of other two bugs, one closed and one open preventing login screen from entering the password – as somebody would be pressing the entry key on and on.

I was not able to find a straight and simple fix unless I’ve hit this solution for Ubuntu, and ported it to Fedora 20:

You can then VNC to port :0 and you will be logged in directly without a need to enter the user password.  I suggest SSH tunneling.

http://www.janbambas.cz/headless-fedora-20-and-vnc-with-autologin/

Consider the following feature and its xpcshell test:

// In a module Foo
function doSomething() {
  // ...
  OS.File.writeAtomic("/an invalid path", "foo");
  // ...
}

// In the corresponding unit test
add_task(function*() {
  // ...
  Foo.doSomething();
  // ...
});

Function doSomething is obviously wrong, as it performs a write operation that cannot succeed. Until we started our work on uncaught asynchronous errors, the test passed without any warning. A few months ago, we managed to rework Promise to ensure that the test at least produced a warning. Now, this test will actually fail with the following message:

A promise chain failed to handle a rejection – Error during operation ‘write’ at …

This is particularly useful for tracking subsystems that completely forget to handle errors or tasks that forget to call yield.

Who is affected?

This change does not affect the runtime behavior of application, only test suites.

• xpcshell: landed as part of bug 976205;
• mochitest / devtools tests: waiting for all existing offending tests to be fixed, code is ready as part of bug 1016387;
• add-on sdk: no started, bug 998277.

This change only affects the use of Promise.jsm. Support for DOM Promise is in bug 989960.

Details

We obtain a rejected Promise by:

• throwing from inside a Task; or
• throwing from a Promise handler; or
• calling Promise.reject.

A rejection can be handled by any client of the rejected promise by registering a rejection handler. To complicate things, the rejection handler can be registered either before the rejection or after it.

In this series of patches, we cause a test failure if we end up with a Promise that is rejected and has no rejection handler either:

• immediately after the Promise is garbage-collected;
• at the end of the add_task during which the rejection took place;
• at the end of the entire xpcshell test;

(whichever comes first).

Opting out

There are extremely few tests that should need to raise asynchronous errors and not catch them. So far, we have needed this two tests: one that tests the asynchronous error mechanism itself and another one that willingly crashes subprocesses to ensure that Firefox remains stable.

You should not need to opt out of this mechanism. However, if you absolutely need to, we have a mechanism for opting out. For more details, see object Promise.Debugging in Promise.jsm.

Any question?

Feel free to contact either me or Paolo Amadio.

http://dutherenverseauborddelatable.wordpress.com/2014/05/30/revisiting-uncaught-asynchronous-errors-in-the-mozilla-platform/