I am deeply honored and humbled by the CEO role. I’m also grateful for the messages of support. At the same time, I know there are concerns about my commitment to fostering equality and welcome for LGBT individuals at Mozilla. I hope to lay those concerns to rest, first by making a set of commitments to you. More important, I want to lay them to rest by actions and results.

A number of Mozillians, including LGBT individuals and allies, have stepped forward to offer guidance and assistance in this. I cannot thank you enough, and I ask for your ongoing help to make Mozilla a place of equality and welcome for all. Here are my commitments, and here’s what you can expect:

• Active commitment to equality in everything we do, from employment to events to community-building.
• Working with LGBT communities and allies, to listen and learn what does and doesn’t make Mozilla supportive and welcoming.
• My ongoing commitment to our Community Participation Guidelines, our inclusive health benefits, our anti-discrimination policies, and the spirit that underlies all of these.
• My personal commitment to work on new initiatives to reach out to those who feel excluded or who have been marginalized in ways that makes their contributing to Mozilla and to open source difficult. More on this last item below.

I know some will be skeptical about this, and that words alone will not change anything. I can only ask for your support to have the time to “show, not tell”; and in the meantime express my sorrow at having caused pain.

Mozilla is a movement composed of different people around the world, working productively together on a common mission. This is important to our ability to work and grow around the world.

Many Mozillians and others know me as a colleague or a friend. They know that I take people as they come and work with anyone willing to contribute. At the same time, I don’t ask for trust free of context, or without a solid structure to support accountability. No leader or person who has a privileged position should. I want to be held accountable for what I do as CEO. I fully expect you all to do so.

I am committed to ensuring that Mozilla is, and will remain, a place that includes and supports everyone, regardless of sexual orientation, gender identity, age, race, ethnicity, economic status, or religion.

You will see exemplary behavior from me toward everyone in our community, no matter who they are; and the same toward all those whom we hope will join, and for those who use our products. Mozilla’s inclusive health benefits policies will not regress in any way. And I will not tolerate behavior among community members that violates our Community Participation Guidelines or (for employees) our inclusive and non-discriminatory employment policies.

You’ll also see more from Mozilla under my leadership in the way of efforts to include potential contributors, especially those who lack privilege. This entails several projects, starting with Project Ascend, which is being developed by Lukas Blakk. I intend to demonstrate with meaningful action my commitment to a Mozilla that lives up to its ideals, including that of being an open and inclusive community.

/be

https://brendaneich.com/2014/03/inclusiveness-at-mozilla/

University of Waterloo engineering students in 1964 Image ©Kitchener Waterloo Record, http://www.flickr.com/photos/48169267@N08/4967256177/in/photolist-8yWucT-eqaQdV-epd6Lw-c5ywEJ-c5yvwd/under Creative Commons by-nc-sa 2.0

http://relengofthenerds.blogspot.com/2014/03/upcoming-release-engineering-events.html

Last year I approached Debbie Cohen, our C-level People person, and made a proposal.  With all these Hacker School/Dev Boot Camp/Hackbright accelerator programs popping up, I had an idea to create an open source version and specifically target participants who come from underemployed, LGBTQ, Latin@, and African American populations – aka: people who are terribly underrepresented in tech but also very much more so in Open Source. The idea was that instead of people paying to come learn to become developers in the capitalist, Startup-focused, feeding-frenzy the Silicon Valley promotes we could instead seed other towns, other communities with open source and create an in-depth technical contribution training program that more mirrored the experience I had with Dave Humphrey at Seneca College. Imagine my surprise when Debbie clearly, and without hesitation said to me “Great idea! Do it!”.  I’ve been building up to something that is more sizeable through running local events, hack meetups, participating in community building in several ways so I saw this proposal as the next step for me, as an organizer.  This time I’m going to do something that is bigger than what I could do alone. I will have Christie Koehler working with me as well as several community building team members in advising and mentoring roles.

The populations I want us to reach out to have resulted in certain adjustments to the typical setup of those for-profit accelerators which I see as being key to the potential success of our cohorts. Attendees in the Ascend Project will benefit from taking this course in the following ways, which are intended to remove many barriers to participation in Open Source:

•  a $50 per day honorarium will be provided to encourage regular attendance and help ensure participants can afford to focus on being present to learn & develop
• laptops will be provided to use during the course and upon completion, graduates will get to keep theirs
• food (breakfast and lunch) will be provided every day
• where needed, childcare stipends are available to participants who need additional care in order to put in the time this course will request of them
• transit passes for the whole 6 weeks

The purpose here is to not only acknowledge that we know we’re missing people in our open source communities but that we’re willing to put our money and time where our mouths are to go and explicitly invite people who like to solve problems to come and see what it is like to get to just focus on learning, developing, fixing a bug, getting hooked, being a part of a bigger community with a mission for global good.  I see this as a solid way to counter the manner in which many of these populations are pushed away from participation in computer science and open source contributions.

We can’t expect every person who might be a strong, longtime, and impactful contributor to Open Source to find us based on passion alone.  That leaves all the systemic issues in society to decide for us who gets here.  If we can remove some barriers and provide an environment where participants in a program get a chance to feel confident, trusted, strong, and *wanted* then we can see how that might blossom their abilities to learn and contribute to an open source project that has a ton of pathways for potential input and impact.

The project is currently still in the kickoff phase so this is the first public post.  Mostly I’m braindumping, trying to work backwards from September when the course will start, and getting my head around who will do what so we get everything ready in time.  I’ve got a budget for the first pilot, which will take place in Portland, OR in the Fall of 2014, and it’s almost approved.  Next up I will be designing the curriculum while Christie works on partnerships locally in preparation for our call for applications.  We’ll be doing our best to reach far outside the typical degrees of separation to get word out and to attract applicants.  I’ll be in Portland next week to meet with local orgs and gather information on where we can promote the project.

Applicants will go through several steps before we whittle down to our final 20.  There will be an expectation that they can complete the highest level of a free, online Javascript course and the Mozilla PDX office will hold drop ins with computers available to help applicants have the time to do this with the right equipment and a mentor or two nearby.  Following that stage, we’ll ask for an essay or video that briefly describes a ‘hard’ problem the person had to solve, if they were successful what worked and if not what didn’t.  Staying away from specific, alienating technology language seems key here. We need problem solvers and self-starters, not people who know syntax (yet).  That group will then be the pool from which the final participants will be selected from, with specific ratio targets for populations that I mentioned earlier.

The first session, as a pilot, will have certain ‘training wheels’ on it. Mozilla has a great space in Portland.  Portland has a wonderfully large open source community I fully expect to tap into for networking and partnerships.  We’ll be using this first pilot as a way to test the participant selection process and the curriculum itself.  I really want to be setting people up for success.  This is measured by committing at least one patch to production code (in any area of Firefox) before the end of the course.  Our first course will focus on Mozmill automated testing because we can get our participants to that level of success with independently-written JS tests for several of the Firefox products.

Following Portland we’ll be reviewing, updating, improving, and then taking the next pilot to New Orleans in January of 2015 where we can test “what happens if we don’t have an office, a large community already in place?” with our tightened up selection process and curriculum.  The two pilots should give us lots to go on for how to scale up an initiative like this going forward and hopefully it can become something that happens more frequently, with more teachers, and in many more places (like in some of our Firefox OS launch markets).

That’s the gist for now.  I’ll be posting more frequently as we hit milestones in the project and also am happy to take people up on offers to review curriculum.

http://lukasblakk.com/ascend-project-kickoff/

Microsoft recently announced that they were enhancing their “SmartScreen” system to send back to Microsoft every SSL certificate that every IE user encounters. They will use this information to try and detect SSL misissuances on their back end servers.

They may or may not be successful in doing that, but this implementation raises significant questions of privacy.

SmartScreen is a service to submit the full URLs you visited in IE (including query strings) to Microsoft for reputation testing and possible blocking. While Microsoft tries to reassure users by saying that this information passes to them over SSL, that doesn’t help much. It means an attacker with control of the network can’t see where you are browsing from this information – but if they have control of your network, they can see a lot about where you are browsing anyway. And Microsoft has full access to the data. The link to “our privacy statement” in the original SmartScreen announcement is, rather worryingly, broken. This is the current one, and it also tells us Each SmartScreen request comes with a unique identifier. That doesn’t contain any personal information, but it does allow Microsoft, or someone else with a subpoena, to reconstruct an IE user’s browsing history. The privacy policy also says nothing about whether Microsoft might use this information to e.g. find out what’s currently trending on the web. It seems they don’t need to provide a popular analytics service to get that sort of insight.

You might say that if you are already using SmartScreen, then sending the certificates as well doesn’t reveal much more information to Microsoft about your browsing than they already have. I’d say that’s not much comfort – but it’s also not quite true. SmartScreen does have a local whitelist for high traffic sites and so they don’t find out when you visit those sites. However (I assume), every certificate you encounter is sent to Microsoft, including high-traffic sites – as they are the most likely to be victims of misissuance. So Microsoft now know every site your browser visits, not just the less common ones.

By contrast, Firefox’s (and Chrome’s) implementation of the original function of SmartScreen, SafeBrowsing, uses a downloaded list of attack sites, so that the URLs you visit are not sent to Google or anyone else. And Certificate Transparency, the Google approach to detecting certificate misissuance after the fact which is now being standardized at the IETF, also does not violate the privacy of web users, because it does not require the browser to provide information to a third-party site. (Mozilla is currently evaluating CT.)

If I were someone who wanted to keep my privacy, I know which solution I’d prefer.

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

Plot Our heroes received their assignment. They had to go deep into the Perflines, in the long lost territory of Session Restore, and do whatever it took to get Session Restore back into Perfland. However, they quickly realized that they had been sent on a mission without return – and without a map. This is their tale.

Session Restore is a critical component of Firefox. This component records the current state of your browser to ensure that you can always resume browsing without losing the state of your browser, even if Firefox crashes, if your computer loses power, or if your browser is being upgraded. Unfortunately, we have had many reports of Session Restore slowing down Firefox. In February 2013, a two person Perf/Fx-team task force started working on the Performance of Session Restore. This task force eventually grew to four persons from Perf, Fx-team and e10s, along with half a dozen of punctual contributors.

To this day, the effort has lasted 13 months. In this series of blg entries, I intend to present our work, our results and, more importantly, the lessons we have learnt along the way, sometimes painfully.

Fixing yes, but fixing what?

We had reports of Session Restore blocking Firefox for several seconds every 15 seconds, which made Firefox essentially useless.

The job of Session Restore is to record everything possible of the state of the current browsing session. This means the list of windows, the list of tabs, the current address of each tab, but also the history of each tab, scroll position, anchors, DOM SessionStorage. session cookies, etc. Oh, and this goes recursively for both nested frames and history. All of this is saved to a JSON-formatted file called sessionstore.js, every 15 seconds of user activity. To this day, the largest reported sessionstore.js files is 150Mb, but Telemetry indicates that 95% of users used to have a file of less than 1Mb (numbers are lower these days, after we spent time eliminating unnecessary data from sessionstore.js).

We started the effort to fix Session Restore from only a few bug reports:

• sometimes, users lost sessionstore.js data;
• sometimes, data collection took ages.

Unfortunately, we had no data on:

• the size of the file;
• the actual duration of data collection;
• how long it took to write data to the disk.

To complicate things further, Session Restore had been left without owner for several years. Irregular patching to support new features of the web and new configurations had progressively turned the code and data structures into a mess that nobody fully understood.

We had, however, a few hints:

• Session Restore needs to collect lots of data;
• Session Restore had been designed a long time ago, for users with few tabs, and when web pages stored very little information;
• serializing and writing to JSON is inefficient;
• in bad cases, saving could take several seconds;
• the collection of data was purely monolithic;
• reading and writing data was done entirely on the main thread, which was a very bad thing to do;
• the client API caused full recollections at each request;
• the data structure used by Session Restore had progressively become an undocumented mess.

While there were a number of obvious sources of inefficiency that we could fix without further data, and that we set out to fix immediately. In a few cases, however, we found out the hard way that optimizing without hard data is a time-consuming and useless exercise. Consequently, a considerable part of our work has been to use Telemetry to determine where we could best apply our optimization effort, and to confirm that this effort yielded results. In many cases, this meant adding coarse-grained probes, then progressively completing them with finer-grained probes, in parallel with actually writing optimizations.

To be continued…

In the next episode, our heroes will fight Main Thread File I/O… and the consequences of removing it.

http://dutherenverseauborddelatable.wordpress.com/2014/03/26/the-battle-of-session-restore-pilot/

• Fedora/Ubuntu debug mochitest-browser-chrome

• Fedora/Ubuntu b2g reftests

http://armenzg.blogspot.com/2014/03/moving-away-from-rev3-minis.html

If I had to say, “what makes Mozilla special?”, I’d probably point to someone like Gorjan, a remarkable guy.

In this blog post, he could brag about the astonishing things he has done n the community at a very tender age.  He could.  Instead, he writes with honesty and humility about volunteering for Free Software projects in his country.

http://patrickfinch.com/2014/03/26/saluting-mozilla-macedonia/

Update sizes up 20-37% since last year!

Mozilla relies on our automatic update infrastructure to make sure that our users are kept up to date with the latest, most secure and fastest browser.

Having smaller updates means users are able to get the latest version of Firefox more quickly.

Since Firefox 19.0 (released just over a year ago - February 16th, 2013) our complete update size for Windows has grown from 25.6MB to 30.9MB for Firefox 28.0 (released March 15th, 2014). That's a 20% increase in just one year. On OSX it's grown from 37.8MB to 47.8MB, a 26% increase.

Partial updates have similarly grown. For Windows, a user coming form 27.0.1 to 28.0 would receive a 14.3MB update compared to a 10.4MB update going from 18.0.2 to 19.0, an increase of 37.5%

This means it's taking users 20-37% longer to download updates than it did last year. Many of our users don't have fast reliable internet, so an increase in update size makes it even harder for them to stay up to date. In addition, this size increase translates directly into bandwidth costs to Mozilla. All else being equal, we're now serving 20-37% more data from our CDNs for Firefox updates this year compared to last year.

Reducing update size

How can we reduce the update size? There are a few ways:

1. Make sure we're serving partial updates to as many users as possible, and that these updates are applied properly. More analysis is needed, but it appears that only roughly half of our users are updating via partial updates.
2. Reduce the amount of code we ship in the update. This could mean more features and content are distributed at runtime as needed This is always a tricky trade-off to make between having features available for all users out of the box, and introducing a delay the first time the user wants to use a feature that requires remote content. It also adds complexity to the product.
3. Change how we generate updates. This is going to be the focus of the rest of my post.

Smaller updates are more better

There are a few techniques I know of to reduce our update sizes:

• Use xz compression instead of bzip2 compression inside the MAR files (bug 641212). xz generally gets better compression ratios at the cost of using more memory.
• Use courgette instead of bsdiff for generating the binary diff between .exe and .dll files (bug 504624). Courgette is designed specifically for diffing executables, and generates much smaller patches than bsdiff.
• Handle omni.ja files more effectively (bug 772868). omni.ja files are essentially zip files, and are using zip style compression. That means each member of the zip archive is individually compressed. This is problematic for two reasons: it makes generating binary diffs between omni.ja files much less effective, and it makes compressing the omni.ja file with bzip2 or xz less effective. You get far better results packing files into a zip file with 0 compression and using xz to compress it afterwards. Similarly for generating diffs, the diff between two omni.ja files using no zip compression is much smaller than the diff between two omni.ja files using the default zip -9 compression.
• Don't use per-file compression inside the MAR file at all, rather compress the entire archive with xz. I simulated this by xz-compressing tar files of the MAR contents.

27% smaller complete updates

We can see that using xz alone saves about 10.9%. There's not a big difference between xz -6 and xz -9e, only a few kb generally. ("xz -6" and "xz -9e" series in the chart)

Disabling zip compression in the omni.ja files and using the standard bzip2 compression saves about 9.7%. ("zip0 .ja" in the chart)

Combining xz compression with the above yields a 24.8% saving, which is 7.6MB. ("zip0 .ja, xz -9e" in the chart)

Finally, disabling zip compression for omni.ja and per-file compression and compressing the entire archive at once yields a 27.2% saving, or 8.4MB.

66% smaller partial updates

Very similar results here for xz, 8.4% savings with xz -9e.

Disabling zip compression in the omni.ja files has a much bigger impact for partial updates because we're able to produce a much smaller binary diff. This method alone is saves 42%, or 6.0MB.

Using courgette for executable files yields a 19.1% savings. ("courgette" in the chart)

Combining courgette for executable files, no zip level compression, and per-file xz compression reduces the partial update by 61%. ("courgette, zip0 .ja, xz -9e" in the chart)

And if we compress the entire archive at once rather than per-file, we can reduce the update by 65.9%. ("courgette, zip0 .ja, tar, xz -9e" in the chart)

Some notes on my methodology: I'm focusing on 32-bit Windows, en-US only. Most of the optimizations, with the exception of courgette, are applicable to other platforms. I'm measuring the total size of the files inside the MAR file, rather than the size of the MAR file itself. The MAR file format overhead is small, only a few kilobytes, so this doesn't significantly impact the results, and significantly simplifies the analysis.

Finally, the code I used for analysis is here.

http://atlee.ca/blog/posts/firefox-update-sizes.html

http://tantek.com/2014/084/b1/urls-people-focused-mobile-communication

I could not be happier to see Brendan Eich become the new CEO of Mozilla

Brendan has a vision, a unique vision that made Mozilla what it is today, and he is a great leader, respected all over the world, all over our geek's world. Reliable, hyper-smart, friendly and knowing perfectly - of course - the organization he co-founded.

But there is one thing I would like to come back to, because I read something too disruptive to me on planet.mozilla.org: yes, Brendan donated to the anti-marriage equality Prop. 8 campaign in California. I don't like, I don't like at all seeing that pop up again in public space because that's pointing an index at someone for his/her beliefs, that's something that should not happen in a community like ours. When Brendan was under attack, two years ago, I sent him my support. Not a support to his opinion, but a support to his freedom of opinion and freedom of expression of that opinion through all legal means. Including a donation.

Seen from Europe with a European point of view, I do not understand how one can complain about it. Mozilla promotes openness and freedom of choice, that's its Manifesto, that's our core values, why most of us contribute to Mozilla. I want that openness and freedom of choice to be a deep, anchored value of the whole Mozilla community. With that in mind, I entirely respect Brendan's personal choice, that was exposed only because of the Californian law and was attached to the name of Mozilla only because that law makes it mandatory to mention the affiliation of the donator above a given level of donation IIRC. I trust - we all trust - Brendan to be able to deal with the whole community - employees or contributors - equally, whatever their own beliefs or personal choices. I met Brendan 14 years ago and have never seen him behave in a different way.

The Mozilla community at large represents quite well the diversity of thoughts on the globe. We have people who love fire weapons; I don't like it but that's legal in their countries. We have people supporting death penalty; I hate it but that's legal in their countries. We have people from all political sides, including extremes; I don't understand it but I accept it. We have people based in countries one could easily qualify as antidemocratic and who support their regime; yes, diversity is a marker of the human kind. And we have people who have diverging opinions about major societal issues, within the limits of the law, absolutely. We even have true nerds, barely social, who can't understand what's a private and family life. So what? Again, seen from Europe and with a European point of view, not a problem at all.

Pointing an index at someone of our community for his/her beliefs can only have one side-effect: people will stop expressing their opinions because they will be afraid of the kickback, people will be blamed in public for legal behaviours and that's totally unacceptable to me as a European. That's not the world I want to live in, that's not my concept of democracy and freedom of opinion/speech. That's not the Mozilla I want. Brendan, I value your opinion, and that does not say anything about my agreement or disagreement with your opinion itself.

We, as a community, cannot promote openness and freedom of choice without a deep respect for individual beliefs. A reminder of Brendan's personal choices years ago is unfair and violates too much for me the core values of the Mozilla community. I am writing this article because I want it to be the very last time we read about it in public space. FWIW, and given the long chats we had about it in Europe two years ago, I think the above is a quite widely shared opinion in the European Mozilla community.

Welcome Brendan, and long life to Moz.

http://www.glazman.org/weblog/dotclear/index.php?post/2014/03/25/Welcome-Brendan%21

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

• [901599] changing the requestee of a pending needinfo flag should redirect the request rather than clearing it
• [983963] Add ability to make any bug in product Audio/Visual Infrastructure -> Confidential Mozilla Employee Bug or Infrastructure-related Bugs
• [985305] update the metrics elasticsearch reporter to bypass es node discovery
• [983045] Change the word “outstanding” in the request nagger emails to “overdue”
• [986124] Allow people to set “See Also” when filing/creating/entering a bug on enter_bug.cgi or the Bug.create webservice
• [978773] API to query flag history by user

discuss these changes on mozilla.tools.bmo.

http://globau.wordpress.com/2014/03/25/happy-bmo-push-day-87/

Or, how to migrate to git using only three programming languages

Another aspect of Bugzilla has been dragged, kicking & screaming, into the future! On March 11, 2014, the Bugzilla source moved to git.mozilla.org. We’re still mirroring to bzr.mozilla.org (more on that later), but the repository of record is now git, meaning it is the only place we accept new code.

Getting over there was no small feat, so I want to record the adventure in the hopes that it can benefit someone else, and so I can look back some day and wonder why I put myself through these things.

Background

The rationale isn’t the focus of this post, but suffice it to say that Bazaar isn’t very widely used, and many projects are abandoning it. Eric S. Raymond wrote a good post on the Emacs dev list about why they need to move from Bazaar to git. The same rationale applies to Bugzilla: “Sticking to a moribund version-control system will compound and exacerbate the project’s difficulty in attracting new talent.”

So, moving on, I started off scouring the Internet to find the best way to perform this migration. One major complication is the fact that we want to keep mirroring (one-way) to Bazaar for at least a while, since the main suggested way to upgrade Bugzilla is from bzr.mozilla.org. It was deemed unreasonable to require existing installations to switch to git to obtain a small security fix, so we’ll continue to mirror changes to Bazaar for some time.

Initial migration

I found a few posts here and there about people who had done migrations like this, but the most useful was a post by David Roth from last year that detailed how to preserve Bazaar’s commit metadata, specifically bug-tracker metadata, which Bugzilla has used on virtually every commit since switching from CVS. It involves using the --no-plain option with bzr fast-export and then translating the output to something git understands.

Interestingly, Roth’s translation script was written in C#, not my personal first choice for such a task (or any, really, since I don’t generally develop for Windows). However it compiled fine under Mono, so I could run it on a Linux box. Something I learned, though, is to not try this kind of thing on OS X, where, by default, the filesystem is case-insensitive.

As much as I’d prefer to deal with a language with which I am more comfortable, I dislike duplicated effort even more. I used Roth’s C# script as a basis, modifying it a bit for our needs. The metadata is in the form . Rather than editing existing commit messages, I just took that string and pasted it to the bottom of the commit message, but only if the bug number was not already in the commit message. This actually revealed a few typos in the “Bug 123456” strings that generally start commit messages.

There turned out to a few other subtle bugs, like the fact that a file which is both renamed and modified in the same commit shows up, in the output from bzr fast-export, as being modified under the original name. Thus if the delete is processed first, it looks like bzr has modified an nonexistent file. Those were easy to see by comparing the contents of every file before and after migration (admittedly just for the last revision).

Since there are a lot of branches on bzr.mozilla.org, I created a bash script to record them all and make sure none were missed. It output the pre-/postmigration diff of md5 sums as well as doing a git repack for each repo, after all branches were migrated.

One thing I forgot was pushing tags via the --tags option to git push; I had to do that manually after the migration. That’s also when I discovered that the same tag existed in several related bzr branches which were all combined into one git repo. This is, of course, not allowed in git. It made me think more about how Bugzilla uses certain tags, like current-stable, which are moved after each release. In git this requires the --force option to git push and is a big no-no if the remote repo is shared. I learned that, in fact, this is also the case in bzr, though perhaps it’s regarded as less of a sin than it is in git. Anyway, I’ve since realized that those should be branches, named appropriately (per branch). Despite them not being branches in the standard sense—they’ll always point to somewhere at or behind a version branch and never fork—it’s perfectly acceptable to move them, as opposed to tags, and since they’ll always be fast-forwarded, they won’t take any more space than a lightweight tag.

Mirroring

This was a harder problem. Originally, I tried to use the bzr-git extension, and it failed when I tried to pull in changes from git. I exchanged some emails with bzr-git’s author, Jelmer Vernooij, and he said that to keep an existing bzr branch in sync with a newly formed git repo is impossible at the moment: “This is essentially the ‘roundtripping’ support that we’ve been trying to achieve with bzr-git for a while. It’s a nontrivial problem (since it requires all semantics from bzr to be preserved when pushing to git).” Considering bzr-git hasn’t had a new release in two years, I won’t be holding my breath.

Luckily (and perhaps somewhat unfortunately) Bugzilla has jumped VCSes before, as I hinted above. With the old bzr-to-cvs script as a starting point, I created a git-to-bzr script—in, of course, Perl, as the original.

This script is essentially an automated way of applying individual commits from a git branch to a bzr branch. For each commit, the entire file tree is copied from a local git clone to a local bzr checkout, bzr add and remove are executed where needed, and the changes committed with the original author, contributor, and date preserved. The script also parses out the standard “Bug X:” commit-message format and passes it to bzr’s --fixes commit option. A file called .gitrev in the bzr repo tracks the associated git commit ID for each bzr commit.

To avoid excessive disk activity, since the script polls git and bzr for changes, the script uses bzr cat to check the contents of the .gitrev file and git ls-remote to get the ID of the last git commit. If they are equal, no further actions are performed.

Summing up

And that, folks, is how you can migrate from bzr to git! The initial migration is pretty straightforward, more so if you don’t care about any bzr commit metadata. It was unfortunate that there was no off-the-shelf way to sync the repos afterwards, but the basic idea isn’t too complicated.

For more, there’s the project page on our wiki, and all the scripts used are in a GitHub repo for your perusal. I’m no VCS expert—I’ve never heavily used bzr, and I’m constantly learning new things about git—but feel free to ask me questions if you want our process further clarified.

http://mrcote.info//blog/2014/03/24/moving-bugzilla-from-bazaar-to-git/

Today Mozilla announced a number of leadership changes, including the appointment of Brendan Eich as CEO. Amid the analysis of the change, there is a lengthy post on Hacker News specifically discussing Brendan’s support of anti-LGBT Prop. 8 in 2008 and whether or not it affects his suitability as CEO.

As a single employee of Mozilla, I am not sure I can definitively determine Brendan’s suitability. I can, however, give insight as to what I experience at Mozilla as a queer woman and how I feel about the appointment.

Mozilla is a very unique organization in that it operates in a strange hybrid space between tech company and non-profit. There simply aren’t a lot of models for what we do. Wikimedia Foundation is always the one that comes closest to mind for me, but remains a very different thing. As such, people with experience relevant Mozilla, relevant enough to lead Mozilla well, are in very short supply. An organization can always choose to make an external hire and hope the person comes to understand the culture, but that is a risky bet. Internal candidates who have demonstrated they get the culture, the big picture of where we need to go and have demonstrated they can effectively lead large business units, on the other hand, present as very strong options.

And, from my limited vantage point, that’s what I see in Brendan.

Like a lot of people, I was disappointed when I found out that Brendan had donated to the anti-marriage equality Prop. 8 campaign in California. It’s hard for me to think of a scenario where someone could donate to that campaign without feeling that queer folks are less deserving of basic rights. It frustrates me when people use their economic power to further enshrine and institutionalize discrimination. (If you haven’t seen it, here’s Brendan’s response to the issue.)

However, during the intervening years, I’ve spent a lot of time navigating communities like Mozilla and figuring out how to get things done. I’ve learned that it’s hard working with people but that you have to do it anyway. I’ve learned that it can be even harder to work with someone when you think you don’t share your fundamental beliefs, or when you think they hold opposing or contradictory beliefs, but you have to do that sometimes, too.

The key is to figure out when it’s important to walk away from interacting with a person or community because of a mis-alignment in beliefs and when you need to set aside the disagreement and commit to working together in service of the shared goal. Context is really important here. What is the purpose or mission of the community? Who is its audience? What are its guiding principles?

Mozilla’s mission is “to promote openness, innovation & opportunity on the Web.” Our audience is the global community of people connecting to the internet. Our guiding principles are numerous, but include protecting the internet as a public resource and upholding user privacy, security and choice.

At the same time, many Mozillians are themselves advocates for human rights, animal rights, prison abolition, marriage equality, racial equality, etc. As much as some of those causes might overlap with the cause of a free and open internet, they are separate causes and none of them are the focus of Mozilla the organization. Focus is important because we live in a world of limited resources. Mozilla needs to stay focused on the mission we have all come together to support and move forward.

Another factor to consider: What is their behavior within the community, where we have agreed to come together and work towards a specific mission? How much does a person’s behavior outside the scope of community affect the community itself? Does the external behavior conflict directly with the core mission of the organization?

To be clear, I’m personally disappointed about Brendan’s donation. However, aside from how it affected me emotionally, I have nothing to indicate that it’s materially hurt my work within the Mozilla community or as a Mozilla employee. Mozilla offers the best benefits I have ever had and goes out of its way to offer benefits to its employees in same-sex marriages or domestic partnerships on par with those in heterosexual marriages. Last year we finally got trans-inclusive healthcare. We didn’t have an explicit code of conduct when I started, but adopted the guidelines for participation within my first year. Progress might be slow, but it’s being made. And I don’t see Brendan standing in the way of that.

Certainly it would be problematic if Brendan’s behavior within Mozilla was explicitly discriminatory, or implicitly so in the form of repeated microagressions. I haven’t personally seen this (although to be clear, I was not part of Brendan’s reporting structure until today). To the contrary, over the years I have watched Brendan be an ally in many areas and bring clarity and leadership when needed. Furthermore, I trust the oversight Mozilla has in place in the form of our chairperson, Mitchell Baker, and our board of directors.

It’s true there might be a kind of collateral damage from Brendan’s actions in the form of some people withdrawing from participation in Mozilla or never joining in the first place. There’s a lot I could say about people’s responses to things that happen at Mozilla, but I’ll save those for another time.

For now, I’ll just say that if you’re queer and don’t feel comfortable at Mozilla, that saddens me and I’m sorry. I understand where you’re coming from, at least in part, because I had a rocky start at Mozilla and often questioned my fit in the community. That’s why I’m putting considerable effort into changing how we interact with and support contributors from marginal groups. If you want to join me, look at what we’re doing with the Education Working Group and then get in touch.

To conclude, what I offer to my fellow Mozillians, including Brendan, is this:

• I respect that you have a private life, including interactions in other communities, that may not match my beliefs or may even conflict with them.
• I recognize that despite possible differences in our personal beliefs, you are just as committed as I am to Mozilla’s mission and have a lot to offer the community.
• I agree, and ask you to do the same, to set aside those differences to create a shared space in which we can work together on the Mozilla mission.
• In that space, we’ll treat each other as human beings, following the participation guidelines, even if doing so will stretch our skills and make us slightly uncomfortable.
• We agree to communicate with honesty and empathy and to find ways to support each other’s work in the project.

http://subfictional.com/2014/03/24/on-brendan-eich-as-ceo-of-mozilla/

Earlier this year I was able to move mozilla.org’s Mercurial infrastructure from using NFS-mounted storage to transitioning to local disk. This was done for several reasons.

1. The Mercurial developers were concerned about race conditions and concurrent write/reads causing service inconsistency between hosts. This became evident when stale file handles started appearing in our apache logs.
2. An extension we wrote (pushlog) was also being served off of NFS. This is a problem not because we have multiple hosts writing at once, but because the file is kept in memory for the lifetime of the hgweb-serving WSGI process, and we’ve experienced that sometimes requests to the pushlog can be served old information.
3. During times of peak activity there was non-trivial IOWait which caused clone times to increase.
4. Netapp licenses aren’t cheap.

This took a lot of effort and coordination with the release engineering team to ensure that downtime was kept minimal and there were no feature or performance regressions along the way.

A large part of the transition was the necessity to rewrite the Puppet module that we use to deploy Mercurial. The module is now available on GitHub for people to comment on and use. Of course, pull requests are appreciated.

Now, on to some stats!

Before:

• Sample size: 1063259
• Mean: 16.9414 seconds per Hg operation (?cmd=getbundle)
• Minimum: 0.000112
• Maximum: 1353.56
• 95th percentile: 19.551 seconds per Hg operation

After:

• Sample size: 536678
• Mean: 15.7102 seconds per Hg opeation (?cmd=getbundle)
• Minimum: 0.000123
• Maximum: 1236.69
• 95th percentile: 19.5716 seconds per Hg operation

From that data we can’t see much significant performance improvement or degradation. I’m hoping that in the future we’ll be able to measure end-to-end client clone time to see better performance. With the local disks we’ll be able to stream uncompressed copies at line speed, which should result in 180 second clone times.

http://bke.ro/?p=380

I doubt anyone who reads this will disagree with the proposition that the Web needs to move toward all traffic being encrypted always. Yet there is constant back pressure in the standards groups, people trying to propose network-level innovations that provide only some of the fundamental three guarantees of a secure channel—maybe you can have integrity but not confidentiality or authenticity, for instance. I can personally see a case for an “authentic” channel that provides integrity and authenticity but not confidentiality, but I don’t think it’s useful enough to back off on the principle that everything should be encrypted always.

So here’s a way browser vendors could signal that we will not stand for erosion of secure channels: starting with a particular, documented and well-announced, version, all new content features are only usable for fully HTTPS pages. Everything that worked prior to that point continues to work, of course. I am informed that there is at least some support for this within the Chrome team. It might be hard to sell Microsoft on it. What does the fox think?

https://www.owlfolio.org/htmletc/should-new-web-features-be-https-only/

I’m excited that Brendan Eich is Mozilla’s CEO. Brendan knows what’s important right now: building the values of the web into mobile and into the cloud at a massive scale. This vision is key to our success. But Brendan also offers something else: a real example of how we can each roll up our sleeves to tackle the hard, messy problems that we need to solve if we want to make this vision into a reality.

When I first came to Mozilla, I was a little starstruck. Here was an organization that had rallied a global community to build Firefox and beat Microsoft. An organization that had made open source — and many of the ideas behind it — mainstream. An organization filled with internet rock stars like Brendan. People who have changed the world, for real.

What I realized quickly: Mozillians are just everyday people. What makes them special is their particular ideas about how to make things happen in the world. Ideas like: build your vision and values into products that lots of people will want to use. And, find leverage, create standards and nurture relationships that help these products shape whole industries. And, do these things by empowering people and inviting them to help you out. Mozilla has won in the past because its people had been smart, tenacious and committed to this particular brand of poetry and pragmatism.

Working with Brendan over the years, I saw someone who everyday personified this Mozilla way of working. Think about Javascript as an example. Most of you probably know that Brendan invented Javascript. But what you might not know is how hard he worked worked internally at Netscape and Mozilla to put Javascript into products that millions of people would use. Or how he collaborated with competitors like Microsoft and Google. Or how he’s worked on standards. Or how much time he’s taken to speak to and inspire developers at events on every corner of the planet. Code matters in the history of Javascript. But so does leadership, business and alliance building. Brendan worked on all of these things over the years, turning Javascript from an idea into a programming language that is used widely and freely everywhere around the world to build the web.

In my opinion, this way of working is something we need more of at Mozilla right now. See the big picture. Roll up our sleeves. Pick the right battles. Make the right compromises. Figure out all the different kinds of things we need to do to win. And help each other out to get these things done.

I truly think Brendan can help us all do more of this right now. He’s already started with Firefox OS, not only leading us to build a compelling product in a few short years but also playing an active role in helping carriers and device manufacturers become partners contributing to Mozilla’s cause. Like always, Brendan has helped us build not just a product but also platforms and relationships that have the potential to shift the whole playing field. As we tackle everything from cloud services to building up new revenue lines to teaching 100s millions of people about the web, I believe Brendan can help each be smart, tenacious, practical and open as we work on solving our particular piece of the open web puzzle.

I’m feeling hopeful and inspired today. I’m looking forward to working closely with Brendan as Mozilla’s new CEO. And to rolling up my sleeves even further to build the web we’re dreaming of. I hope you want to do the same.

http://commonspace.wordpress.com/2014/03/24/excited-about-eich/

# assuming HEAD is the commit to split,
git reset HEAD^ # first undo the commit
git add -p      # then choose bits to separate out
git commit      # commit separated changes
git commit -a   # commit other changes

# assuming HEAD is the commit to split,
# first, in Your Favorite Editor, delete everything that you want to separate out
git commit -a --fixup HEAD        # then commit the changes you removed as a fixup
git revert -e HEAD                # revert the fixup; this will become the split commit
git rebase -i --autosquash HEAD~3 # combine the original commit and the fixup

http://www.jnchen.com/blog/2014/03/splitting-a-git-commit-into-two

http://relengofthenerds.blogspot.com/2014/03/eclipsecon-2014-trip-report.html

Hello Mozillians!

This is just a quick note to the blog readers about a new page on MDN: How to customize the Firefox Web Console output. The API presented is fully available in the Aurora channel, and partially available in the beta release channel.

I hope add-on authors interested to extend the developer tools will find the documentation useful.

http://www.robodesign.ro/mihai/blog/how-to-customize-the-firefox-web-console-output?ref=feed&reftype=entry-link

A quick note to update everyone on Mozilla news. Our Board of Directors has appointed me CEO of Mozilla, with immediate effect. I’m honored and humbled, and I promise to do everything I can to lead Mozilla to new heights in this role.

I would first like to thank Jay Sullivan for his contributions to Mozilla and to the Web. He has been a passionate force at Mozilla whose leadership, especially during the last year, has been important to our success, in particular with Firefox OS. Jay is helping with the CEO transition and will then leave to pursue new opportunities.

My co-founder and 15-year partner in Mozilla, Mitchell Baker, remains active as Executive Chairwoman of Mozilla. I could not do what I do for Mozilla without Mitchell, and I like to think she feels the same way about me ;-). We have worked together well since she took on management of the tiny mozilla.org staff fragment embedded in Netscape. At that time I was “acting manager” (more like method acting manager :-P). I’ve learned a lot from Mitchell and my other peers at Mozilla about management since then!

Mozilla is about people-power on the Web and Internet — putting individual users, who create as well as consume, above all other agendas. In this light, people-fu trumps my first love, which you might say is math-fu, code-fu or tech-fu (if I may appropriate the second syllable from kung fu). People around the world are our ultimate cause at Mozilla, as well as source of inspiration and ongoing help doing what we do.

Speaking of people a bit more, I’ll take this moment to introduce Li Gong as my incoming COO. Li set up Mozilla China and our Taipei office, and he has been a crucial partner in building up Firefox OS. If you don’t know him yet, you will probably get a chance if you pass through our headquarters, as Li will be moving back to the US to help manage here.

Mozilla remains a global public benefit organization, so I’m sure I will see all of you more as I travel: to all of our offices (I have not yet been to Beijing or Taipei), to the places where we are bringing Firefox OS and the $25 smartphone, and everywhere Mozillians, developers, and others are working to make the Web better for everyone.

/be

https://brendaneich.com/2014/03/mozilla-news/