Firefox 36 (Desktop and Mobile) is now available on the beta channel.
The release notes are published on the Mozilla website:
This version introduces many new HTML5/CSS features, in particular the Media Source Extensions (MSE) API which allow native HTML5 playback on YouTube. The new preferences implementation is also enabled for the first half of the beta cycle, please help us to test this new feature!
On the mobile version of Firefox, we are also shipping the new Tablet user interface!
Download this new version:
And as usual, please report any issues.
1. micro: how might we promote the unique Privacy Day content on the splash page for the 28th?
2. macro: how might we incorporate promotional interest-based content into the real estate on the Webmaker splash page on an ongoing basis?
Constraints: needs to be conceived, designed and implemented within 2 weeks.
Start from the beginning
I took a look at the current splash page. The content that we are promoting is directly connected to the Mozilla mission, so I identified a sliver of space directly above the section where we state the project's values. My thinking here is that we are creating a three tier hierarchy of values on the page: 1) we are webmaker - we are all about making - and this is what you can do right this second to get started, 2) we are deeply concerned about [privacy] - and this what you can do right now to dive into that topic and 3)we are more than just making + [privacy] - here are all the things that we value.
I SEE what you did thereThat sliver was great, but it was below the non-existent but deeply considered fold of the page. If this was a painting I would create a repoussoir element to bring the users attention to the core content by framing the edge. In the painting below you can see that tree branch that directs your attention directly into the heart of the composition.
Jacob Isaaksz. van Ruisdael, The Jewish Cemetery (1655-60)
Building off of my thinking from designing the Mozilla snippet and the onboarding ux, I wanted to make this repoussoir element something that a user might find quirky, whimsical or relateable. All of the other elements on the page were expected and kind of standard elements for a webpage. I needed to create something that would be subtle yet attention grabbing. Looking at subject of privacy, I immediately had associations with corporations and individuals big- brothering me as I visited web pages. I realized that the activity we were directing users to was called private eye - and this led me to create a small asset that features an eyeball that follows your cursor around as you explore the splash page. On hover it will flip and direct you to the activity.This worked for desktop, but for mobile we would have to simulate the action by having a simple CSS eyeball animation center aligned on the sliver. Major props here go out to Aki who had to invoke the pythagorean theorem to get the eye to follow the cursor without leaving the sclera.
I did a study of eyeballs on redpen and immediately got a ton of community and staff feedback - which told me two things: 1. it was a conversation topic and 2. people liked the very first eyeball that I drew.
— Social Justice Mage (@gesa) January 14, 2015
Let me give you a walk through
From Mozilla's perspective, we are testing:
- whimsy vs. traditional promotional placement
- mission driven content
- how many people are we getting to engage with Webmaker and sign up for new accounts
What's Next Up:
- This will be deployed on staging on Monday and then our goal is to go live on January 28th, which is Privacy Day!
- Now that we have a promotional framework, figuring out how to incorporate a richer learning experience around mission - based content.
- Users can opt into enrolling in a sustained challenge - based Webmaker activity. Almost as if it's a virtual Webmaker club.
Shout outs to the team that made this possible: Aki, Andrew, Erika, Paul Johnson, Dave
This is the last in a series of blog posts outlining Pontoon development in 2014. I’ll mostly focus on new features targeting translators. If you’re more interested in developer oriented updates, please have a look at the release notes.
In the past years, Pontoon has come a long way from an idea, a prototype, to a working product. As of today, there’s a dozen of Mozilla projects available for localization in Pontoon. If you want to move it even further, there are plenty of ways to do so.
Start learning how things work by looking at the new Pontoon homepage, which is also used as a demo project to be translated using Pontoon. Perhaps you can translate it to your mother language. You can also learn more advanced features.
Making your website or web application localizable with Pontoon is quick and easy. A simple script needs to be added and you are halfway through. Follow implementation instructions for more details.
Do you have ideas for improvement? Are you a developer? Learn how to get your hands dirty. It has never been easier to set up development environment and start contributing. We’re on GitHub.
Last Thursday we had our weekly call about the Reps program, where we talk about what’s going on in the program and what Reps have been doing during the last week.
- Data Privacy Day.
- Hello Campaign.
- Womoz Update.
- Event metrics challenges update.
- Mozlandia videos.
- How we can improve reports to be more easy?
- Reps and schools.
Don’t forget to comment about this call on Discourse and we hope to see you next week!
Every once in a while you will find someone saying something “bad” about a product of the company they work for. This could be employees or – god forbid – even official spokespeople.
It happens to me, too, for example when my browser crashes on me. The inevitable direct response to this is most of the time some tweet in the style of:Should a spokesperson of $company talk badly about it? Think about the followers you have and what that means for the people who worked on the product!
It is a knee-jerk reaction making a lot of assumptions:
- that the person is not rooting for the team,
- that the person is abusing his or her reach,
- that the intentions are to harm with this,
- that criticising a product means criticising the company and
- that the person has no respect for his or her colleagues.
Or, that they are bad at their job and cause a lot of damage without meaning to and should be chastised by some other person on Twitter.
All these could be valid points, had the person mentioneded something in a terrible way or without context. It is – of course – bad style and not professional for any employee to speak ill of their employer or its products publicly.
However, things go wrong and things break, and no matter if you are a professional spokesperson or not, it is simply honest to mention that. It also begs the question what is better: help the team that build a product to fix an obvious issue by owning the fixing process or to wait till someone else finds it? The latter means you’ll have a much shorter time to fix it.
It is ironic that an audience who hates sales pitches and advertisement is complaining when an official advocate of something points out a flaw.
It all comes down to how you mention an issue. You can cause a lot of good by mentioning an issue. Or you could cause a lot of problems.How to report a failure and make it useful
Things you do by mentioning a fault:
- You admit that things go wrong for you, too. That makes you a user of your products, not a salesperson (or shill, really)
- You mention the fault before somebody else does. This puts you in the driver’s seat. Instead of reacting to criticism, you advertise that you are aware of the issue and that you are looking into it. It is better when you find a flaw than when the competition does.
- You show that you are a user of the product. There is nothing worse than a spokesperson who only listens to what the marketing team talks about or who starts believing exclusively in their own “feel good” messages about a product. You need to use the product to be able to talk about it. And this means that you inevitably will find problems.
- You stay approachable and honest. Things go wrong for all of us – you are no exception.
Of course, just complaining is bad form. To make your criticism something useful, you should do more:
- Be detailed about your environment. Did you use a developer edition of your product? What’s your setup? When did the thing go wrong?
- Stick to one thing that goes wrong. “Browser $x is unstable” is a bad message, “$x just crashed on me when trying to play this video/game” is an OK one.
- You should report the problem internally. In the best case, this should happen before you mention it. You can then follow up your public criticism with a report how the issue is being dealt with. This step is crucial and in many cases you already find a reason why something is broken. You can then mention the issue and the solution at the same time. This is powerful – people like solutions.
- Investigate what happened. Other people might run into the same issue and there is nothing more powerful than a post somewhere on how to fix an issue. Don’t let the thing just lie and be broken. And don’t let people come up with quick fixes or workarounds that might prove to be harmful in the long run.
- Deal with the feedback. People fixing the issue shouldn’t have this as an extra burden. This is where your job as a spokesperson comes in: deal with feedback in a grown-up fashion and keep people updated when things get fixed or more information is unearthed why something happens.
It is very tempting to just vent when something goes wrong. This is not good. Count to ten and consider the steps above first. I am not saying that you shouldn’t report things that annoy you. On the contrary, it is part of your job to do that as it shows that you care about the product. It makes a lot of sense though to turn your gripes into actions.When not to mention an issue
There are times though when you should not mention an issue. Not many, but there are. It mostly boils down to who will suffer by you mentioning the problem.
- Don’t punish your users. It is a bad idea to publicly talk about a security flaw that would endanger your users. That needs immediate fixing and any public disclosure just makes it harder to fix the problem. It also is a feast for the tech press. People love a security drama and you and your press people will have to deal with a lot of half-truths and hyperbole by the press. You don’t want a bug tarnish the trust in your company as a whole, and this is what happens with premature security issue reports and the inevitable spin the press is wont to give it.
- Don’t report without knowing who can fix the issue. Investigate who is responsible and give them a heads up. Failing this will cause massive bad blood in the company and you don’t want to have to deal with public feedback and internal grumblings and mistrust at the same time. A scorned developer is not one that will do things for you or help fixing the issue. They are much more likely to join the public conversation and strongly disagree with you and other critics. Be the person who helps fixing an issue by showing your colleagues in a light that they deal with problems swiftly and professionally. Don’t throw blame into the unknown.
- Don’t report your own faults as problems. You might have a setup that is very unique and causes issues. Make sure you can reproduce the issue in several environments and not just one setting in a certain environment. Make sure you used the product correctly. If you didn’t, write about how you used it wrongly to avoid other false reports of bugs.
Reporting bad things happening without causing internal and external issues requires good communication skills. The most important part is keeping everyone involved in the loop and be very open about the fixing process. If you can’t be sure that things will get fixed, it might not be worth your while to report them publicly. It would be a kind of blackmail or blame game you can not turn into something useful. Instead, be prepared to respond when others find the problem – as inevitably they will.
Stay honest and open and there is no problem with reporting flaws.
Bugzilla has played a major role in the Firefox development process for over 15 years. With upcoming changes to how code changes to Firefox are submitted and reviewed, I think it is time to revisit the central role of Bugzilla and bugs in the Firefox development process. I know this is a contentious thing to say. Please, gather your breath, and calmly read on as I explain why I believe this.
The current Firefox change process defaults to requiring a Bugzilla bug for everything. It is rare (and from my experience frowned upon) when a commit to Firefox doesn't reference a bug number. We've essentially made Bugzilla and a bug prerequisites for changing anything in the Firefox version control repository. For the remainder of this post, I'm going to say that we require a bug for any change, even though that statement isn't technically accurate. Also, when I say Bugzilla, I mean bugzilla.mozilla.org, not the generic project.
Before I go on, let's boil the Firefox change process down to basics.
At the heart of any change to the Firefox source repository is a diff. The diff (a representation of the differences between a set of files) is the smallest piece of data necessary to represent a change to the Firefox code. I argue that anything more than the vanilla diff is overhead and could contribute to process debt. Now, there is some essential overhead. Version control tools supplement diffs with metadata, such as the author, commit message, and date. Mozilla has also instituted a near-mandatory code review policy, where changes need to be signed off by a set of trusted individuals. I view both of these additions to the vanilla diff as essential for Firefox development and non-negotiable. Therefore, the bare minimum requirements for changing Firefox code are a diff plus metadata (a commit/patch) and (almost always) a review/sign-off. That's it. Notably absent from this list is a Bugzilla bug. I argue that a bug is not strictly required to change Firefox. Instead, we've instituted a near-universal policy that we should have bugs. We've chosen to add overhead and process debt - interaction with Bugzilla - to our Firefox change process.
Now, this choice to require all changes be associated with bugs has its merits. Bugs provide excellent anchor points for historical context and for additional information after the change has been committed and is forever set in stone in the repository (commits are immutable in Mercurial and Git and you can't easily attach metadata to the commit after the fact). Bugs are great to track relationships between different problems or units of work. Bugs can even be used to track progress towards a large feature. Bugzilla components also provide a decent mechanism to follow related activity. There's also a lot of tooling and familiar process standing on top of the Bugzilla platform. There's a lot to love here and I don't want diminish the importance of all these things.
When I look to the future, I see a world where the current, central role of Bugzilla and bugs as part of the Firefox change process begin to wane. I see a world where the benefits to maintaining our current Bugzilla-centric workflow start to erode and the cost of maintaining it becomes higher and harder to justify. You actually don't have to look too far into the future: that world is already here and I've already started to feel the pains of it.
A few days ago, I blogged about GitHub and its code first approach to change. That post was spun off from an early draft of this post (as were the posts about Firefox contribution debt and utilizing GitHub for Firefox development). I wanted to introduce the concept of code first because it is central to my justification for changing how we do things. In summary, code first capitalizes on the fact that any change to software involves code and therefore puts code front and center in the change process. (In hindsight, I probably should have used the term code centric, because that's how I want people to think about things.) So how does code first relate to Bugzilla and Firefox development?
Historically, code review has occurred in Bugzilla: upload a patch to Bugzilla, ask for review, and someone will look at it. And, since practically every change to Firefox requires review, you need a bug in Bugzilla to contain that review. Thus, one way to view a bug is as a vehicle for code review. Not every bug is just a code review, of course. But a good number of them are.
The only constant is change. And the way Mozilla conducts code review for changes to Firefox (and other projects) is changing. We now have MozReview, a code review tool that is not Bugzilla. If we start accepting GitHub pull requests, we may perform reviews exclusively on GitHub, another tool that is not Bugzilla.
(Before I go on, I want to quickly point out that MozReview is nowhere close to its final form. Parts of MozReview are pretty bad right now. The maintainers all know this and we have plans to fix it. We'll be in Toronto all of next week working on it. If you don't think you'll ever use it because parts are bad today, I ask you to withhold judgement for a few more months.)
In case you were wondering, the question on whether Bugzilla should always be used for code review for Firefox has been answered and that answer is no. People, including maintainers of Bugzilla, realized that better-than-Splinter/Bugzilla code review tools exist and that continuing to invest time to develop Bugzilla/Splinter into a best-in-class code review tool would be better spent integrating Bugzilla with an existing tool. This is why we now have a Review Board based code review tool - MozReview - integrated with Bugzilla. If you care about code quality and more powerful workflows, you should be rejoicing at this because the implementation of code review in Bugzilla does not maximize optimal outcomes.
The world we're moving to is one where code review occurs outside of Bugzilla. This raises an important question: if Bugzilla was being used primarily as a vehicle for code review, what benefit and/or role should Bugzilla play when code review is conducted outside of Bugzilla?
I posit that there are a class of bugs that won't need to exist going forward because bugs will provide little to no value. Put another way, I believe that a growing number of commits to the Firefox repository won't reference bugs.
Come with me on a journey to the future.
MozReview is purposefully being designed in a code and repository centric way. To initiate the formal process for considering a change to code, you push to a Mercurial (or Git!) repository. This could be directly to Mozilla's review repository. If I have my way, this could even be kicked off by submitting a pull request on GitHub or Bitbucket. No Bugzilla attachment uploading here: our systems talk in terms of repositories and commits. Again, this is by design: we don't want submitting code to Mozilla to be any harder than hg push or git push so as to not introduce process debt. If you have code, you'll be able to send it to us.
In the near future, MozReview will stop cross-posting detailed review updates to Bugzilla. Instead, we'll use Review Board's e-mail feature to send its flavor of emails. These will have rich HTML content (or plain text if you insist) and will provide a better experience than Bugzilla ever will. We'll adopt the model of tools like Phabricator and GitHub and only post summaries or links of activity, not full content, to bugs. You may be familiar with the concept as applied to the web: it's called hyperlinking.
Work is being invested into Autoland. Autoland is an automated landing queue that pushes/lands commits semi-automatically once they are ready (have review, pass automation, etc). Think of Autoland as a bot that does all the labor intensive and menial actions around pushing that you do now. I believe Autoland will eventually handle near 100% of pushes to the Firefox repository. And, if I have my way, Autoland will result in the abolishment of integration branches and merge commits in the Firefox repository. Good riddance.
MozReview and Autoland will be highly integrated. MozReview will be the primary user interface for interacting with Autoland. (Some of this should be in place by the end of the quarter.)
In this world, MozReview and its underlying version control repositories essentially become a database of all submitted, pending, and discarded commits to Firefox. The metaphorical primary keys of this database are not bug numbers: they are code/commits. (Code first!) Some of the flags stored in this database tell Autoland what it should do. And the MozReview user interface (and API) provide a mechanism into controlling those flags.
Landing a change in Firefox will be initiated by a simple action such as clicking a checkbox in MozReview. (That could even be the Grant Review checkbox.) Commits cleared for landing will be picked up by Autoland and eventually automatically pushed to the Firefox repository (assuming the build and test automation is happy, of course). Once Autoland takes control, humans are just passengers. We won't be bothered with menial tasks like updating the commit message to reflect a review was performed: this will happen automatically inside MozReview or Autoland. (Although, there's a chance we may adopt some PGP-based signing to more strongly convey review for some code changes in order to facilitate stronger auditing and trust guarantees. Stay tuned.) Likewise, if a commit becomes associated with a bug, we can add that metadata to the commit before it is landed, no human involvement necessary beyond specifying the link in the MozReview web UI (or API). Autoland/MozReview will close review requests and/or bugs automatically. (Are you excited about performing less work yet?)
When commits are added to MozReview, MozReview will read metadata from the repository they came from to automatically determine an appropriate reviewer. (We plan to leverage moz.build files for this in the case of Firefox.) This should eliminate a lot of process debt around choosing a reviewer. Similar metadata will also be used to determine what Bugzilla component a change is related to, static analysis rules to use to critique the phsyical structure of the change, and even automation jobs that should be executed given the set of files that changed. The use of this metadata will erode significant process debt around the change contribution workflow.
As commits are pushed into MozReview/Autoland, the systems will be intelligent about automatically tracking dependencies and facilitating complex development workflows that people run into on a daily basis.
If I create a commit on top of someone else's commit that hasn't been checked in yet, MozReview will detect the dependency between my changes and the parent ones. This is an advantage of being code first: by interfacing with repositories rather than patch files, you have an explicit dependency graph embedded in the repository commit DAG that can be used to aid machines in their activities.
It will also be possible to partially land a series of commits. If I get review on the first 5 of 10 commits but things stall on commit 6, I can ask Autoland to land the already-reviewed commits so they don't get bit rotted and so you have partial progress (psychological studies show that a partial reward for work results in greater happiness through a sense of accomplishment).
Since initiating actions in MozReview is light weight (just hg push), itch scratching is encouraged. I don't know about you, but in the course of working on the Firefox code base, I frequently find myself wanting to make small, 15-30s changes to fix something really minor. In today's world, the overhead for these small changes is often high. I need to upload a separate patch to Bugzilla. Sometimes I even need to create a new bug to hold that patch. If that patch depends on other work I did, I need to set up bug dependencies then worry about landing everything in the right order. All of a sudden, the overhead isn't worth it and my positive intentions go unacted on. Multiplied by hundreds of developers over many years, and you can imagine the effect on software quality. With MozReview, the overhead for itch scratching like this is minor. Just make a small commit, push, and the system will sort everything out. (These small commits are where I think a bugless process really shines.)
This future world revolves around code and commits and operations on them. While MozReview has review in its name, it's more than a review tool: it's a database and interface to code and its state.
In this code first world, Bugzilla performs an ancillary role. Bugzilla is still there. Bugs are still there. MozReview review requests and commits link to bugs. But it is the code, not bugs, that are king. If you want to do anything with code, you interact with the code tools. And Bugzilla is not one of them.
Another way of looking at this is that nearly everything involving code or commits becomes excised from Bugzilla. This would relegate Bugzilla to, well, an issue/bug tracker. And - ta da - that's something it excels at since that's what it was originally designed to do! MozReview will provide an adequate platform to discuss code (a platform that Bugzilla provides today since it hosts code review). So if not Bugzilla tools are handling everything related to code, do you really need a bug any more?
This is the future we're trying to build with MozReview and Autoland. And this is why I think bugs and Bugzilla will play a less central role in the development process of Firefox in the future.
Yes, there are many consequences and concerns about making this shift. You would be rational to be skeptical and doubt that this is the right thing to do. I have another post in the works that attempts to outline some common conerns and propose solutions to many of them. Before writing a long comment pointing out every way in which this will fail to work, I encourage you to wait for that post to be published. Stay tuned.
[Update 2014-01-16: A point of clarification. There are two possible ways to send a password for IRC. One is supported in the Instantbird UI – it’s the one that automatically identifies your nick with NickServ, the bot which makes sure people don’t steal other people’s nicks. The other, which is rarer but which I needed, involves sending a password to connect at all, using the PASS command in the IRC protocol. That is what is documented here.]
I was trying to do this; turns out it currently requires about:config manipulation and is not documented anywhere I can find.
Using about:config (type /about config in a message window, or access via Preferences), set the following prefs:messenger.account.accountN.options.serverPassword messenger.account.accountN.options.username
to the obvious values. Other useful tip: if the IRC server uses a self-signed cert, connect to it on the right port using Firefox and HTTPS, and you can save the cert out of the warning/exception dialog you get. You can then import it into Instantbird using the deeply-buried Certificate section of the Advanced Preferences and it will trust the cert and connect. (I think this is what I did, although memory is hazy.)
Mozilla’s Release Engineering team has been through several major iterations of our “release automation”, which is how we produce the bits for Firefox betas and releases. With each incarnation, the automation has become more reliable, supported more functionality, and end-to-end time has reduced. If you go back a few years to Firefox 2.0 it took several days to prepare 40 or so locales and three platforms for a release; now it’s less than half a day for 90 locales and four platforms. The last major rewrite was some time ago so it’s time to embark on a big revamp – this time we want to reduce the end-to-end time significantly.
Currently, when a code change lands in the repository (eg mozilla-beta) a large set of compile and test jobs are started. It takes about 5 hours for the slowest platform to complete an optimized build and run the tests, in part because we’re using Profile-Guided Optimization (PGO) and need to link XUL twice. Assuming the tests have passed, or been recognized as an intermittent failure, a Release Manager will kick off the release automation. It will tag the gecko and localization repositories, and a second round of compilation will start, using the official branding and other release-specific settings. Accounting for all the other release work (localized builds, source tarballs, updates, and so on) the automation takes 10 or more hours to complete.
The first goal of the revamp is to avoid the second round of compilation, with all the loss of time and test coverage it brings. Instead, we’re looking at ‘promoting’ the builds we’ve already done (in the sense of rank, not marketing). By making some other improvements along the way, eg fast generation of partial updates using funsize, we may be able to save as much as 50% from the current wall time. So we’ll be able to ship fixes to beta users more often than twice a week, get feedback earlier in the cycle, and be more confident about shipping a new release. It’ll help us to ship security fixes faster too.
We’re calling this ‘Build Promotion’ for short, and you can follow progress in Bug 1118794 and dependencies.
So far I’ve really been enjoying the challenge of figuring out how to fix the bugs/create the features that I have been tasked with. I’ve been finding that it takes about a day for me to really grasp what to do and then once I’m able to figure that out things feel a bit smoother. My mentor (Will Kahn-Greene) and I have a schedule in terms of the time it should take for me to do short, medium, and large bugs. So far I’ve more or less been able to stick to that schedule.
The bug that I’m nearly finished with right now involves writing code that will determine which variation of the thank you page people will be sent to after giving feedback on input.mozilla.org. I had a bit of trouble the first day, but after talking to my Will, looking at documentation, and searching Safari Books it ended up being pretty straight forward. What was nice about this bug is that I was able to tame the discouragement that I was feeling in the beginning and, low and behold, it looks like things worked out. I’m also quickly learning to try not to over think things – that simple solutions do exist.
Preparations for RelEngConf 2015 are officially in full swing. This means two things:
1) RelEngCon 2015 is now accepting proposals for talks/sessions. If you have a good industry-related or academic-focused topic in the area of Release Engineering, please have a look at the Release Engineering conference guidelines, and submit your proposal before the deadline of 23-jan-2015.
2) Both RelEngCon 2014 and RelEngCon 2013 were great. The mixture of attendees and speakers, from academia and battle-hardened industry, made for some riveting topics and side discussions. Its too early to tell who exactly will be speaking in 2015, but its not too early to start planning your travel to Florence, Italy!! Also of note: RelEngCon 2015 will be just a few weeks after the publication of IEEE 1st Special Issue on Release Engineering. Looks like RelEngConf 2015 is going to be special also.
For further details about the conference, or submitting proposals, see http://releng.polymtl.ca/RELENG2015/html/index.html. If you build software delivery pipelines for your company, or if you work in a software company that has software delivery needs, I recommend you follow @relengcon, block off May 19th, 2015 on your calendar and book now. It will be well worth your time.
See you there!
A rather long time ago I blogged about my work to better deal with changing networks while Firefox is running, and the change was then pushed for Android and I subsequently pushed the same functionality for Firefox on Mac.
Today I’ve landed yet another change, which detects network changes on Firefox OS and Linux.
As Firefox OS uses a Linux kernel, I ended up doing the same fix for both the Firefox OS devices as for Firefox on Linux desktop: I open a socket in the AF_NETLINK family and listen on the stream of messages the kernel sends when there are network updates. This way we’re told when the routing tables update or when we get a new IP address etc. I consider this way better than the NotifyIpInterfaceChange() API Windows provides, as this allows us to filter what we’re interested in. The windows API makes that rather complicated and in fact a lot of the times when we get the notification on windows it isn’t clear to me why!
The Mac API way is what I would consider even more obscure, but then I’m not at all used to their way of doing things and how you add things to the event handlers etc.
The journey to the landing of this particular patch was once again long and bumpy and full of sweat in this tradition that seem seems to be my destiny, and this time I ran into problems with the Firefox OS emulator which seems to have some interesting bugs that cause my code to not work properly and as a result of that our automated tests failed: occasionally data sent over a pipe or socketpair doesn’t end up in the receiving end. In my case this means that my signal to the child thread to die would sometimes not be noticed and thus the thread wouldn’t exit and die as intended.
I ended up implementing a work-around that makes it work even if the emulator eats the data by also checking a shared should-I-shutdown-now flag every once in a while. For more specific details on that, see the bug.
ThinkFWD is a quarterly speaker series focusing on important issues at the intersection of tech and politics. The tech community is great at solving problems....