In 2012 the southern fried chicken restaurant Chick-Fil-A became the unlikely battlefield for marriage equality in America. Through a strange turn of events, same-sex marriage advocates and opponents converged on Chick-Fil-A franchises across the country. People lined up to buy chicken sandwiches in solidarity or to stage a boycott.

One thing’s for sure. If you eat at Chick-Fil-A, your money will support anti-gay causes. So if the long march of progress makes a fast food drive-thru a site of civic participation, well, that’s surreal—but it’s democracy in action.

This evening draws the conclusion of 11 disheartening days at Mozilla: the brief tenure of its co-founder as CEO. So why am I thinking about chicken sandwiches?

Eich is one of maybe a dozen living individuals who can claim to have built the open web. In 15 years of working at Mozilla, Eich never let his personal beliefs color his work. He and others grew Mozilla from a hobby into a world changing social movement. And, incredibly, they did it in a completely apolitical way.

But Eich as CEO was symbolic to a lot of people. It’s why people like Hampton Catlin and his husband, co-owners of a web development firm, took a stand. They and others called for Eich to apologize for funding the Prop 8 campaign or to step down. (I have complete respect for Hampton and have enjoyed several very constructive conversations with him over the past two weeks.)

The crisis that emerged over this issue was partially self-inflicted. We failed to manage the crisis. And a lot of our own people acted badly—from the top on down. We acknowledge this:

We didn’t act like you’d expect Mozilla to act. We didn’t move fast enough to engage with people once the controversy started. We’re sorry. We must do better.

At the same time, gestures from OKCupid and others show that our biggest problem is that the world does not know the story of Mozilla. Especially as a progressive at Mozilla, it was hard to watch as people who should know better pulled out the Chick-Fil-A playbook.

Contrast Chick-Fil-A with Mozilla. The Atlanta-based company has donated upwards of $5 million dollars to PACs opposed to same-sex marriage, and the company’s chief operating officer is on record that same-sex marriage advocates were “inviting God’s judgement on the nation.” Mozilla is a collective of happy mutants who want to make the world better, whose original logo was designed by Shepherd Fairey.

Mozilla was never Chick-Fil-A. A user’s decision to use Firefox would never fund anti-gay causes. The first reason is that we’re not a profit-seeking organization. The second reason is that we would never fund anti-gay causes!

We watched this week as Mozilla, a global non-profit and volunteer community making a free product to benefit humanity, was stained with the taint of homophobia, retrograde opinions, and hate.

It was an expensive moral panic. And though I am heartened that people like Andrew Sullivan feel the same:

Will he now be forced to walk through the streets in shame? Why not the stocks? The whole episode disgusts me – as it should disgust anyone interested in a tolerant and diverse society. If this is the gay rights movement today – hounding our opponents with a fanaticism more like the religious right than anyone else – then count me out. If we are about intimidating the free speech of others, we are no better than the anti-gay bullies who came before us.

…it’s still our fault. This was a critical test of our ability to tell our story, and we failed.

To many of the people who drew incorrect conclusions about Mozilla and our character, we might as well be selling chicken sandwiches.

What do we do from here? Mozilla needs to do a better job of explaining how we’re different. We need to play to our strengths—community, disruptive innovation, doing things in unconventional ways. Even in this storm, you could see some of those silver linings.

Mozilla needs to re-embrace the core of who we are and where we came from. In our products, in our initiatives, in our leadership. Let’s take on big challenges and pick fights again. Let’s not be like the other guys, and make sure the world knows it.

The great irony of all this is that Brendan Eich would have been the best person to return to us to these roots.

For the record, I don’t believe Brendan Eich is a bigot. He’s stubborn, not hateful. He has an opinion. It’s certainly not my opinion, but it was the opinion of 52% of people who voted on Prop 8 just six years ago, and the world is changing fast.

Most of this is ambiguous. Some of it is painful. I am equally disappointed in Mozillians and in demagogues who didn’t see the irony in hounding someone for their private opinion because of “intolerance.”

But one thing is clear: we need to treat all good people with respect and dignity, regardless of who they are or what they believe. I am glad now that the world will have a chance to know our character. And I am grateful to Brendan Eich for all that he’s done for the open web. I hope that in time he will find a way to return to the project and provide the technical leadership that Mozilla, and the world, so greatly needs.

http://www.benmoskowitz.com/?p=971

It's a very sad day. I just landed in San Francisco and learned about Brendan's resignation and I am totally shocked. I have very mixed feelings today about the "Mozilla Community" and I am not sure I like what it became.

Mitchell wrote the following:

We welcome contributions from everyone regardless of age, culture, ethnicity, gender, gender-identity, language, race, sexual orientation, geographical location and religious views. Mozilla supports equality for all.

Yes, we do. But I think we also value democracy, and what happened during the last days seems to be a negation of democracy. One should be able to express legal opinions without having to face a witch-hunt-like repression.

Today, Mozilla is weaker because of this witch hunt. Mozilla, who is standing for the better of everyone on the Web, is weaker because some people thought it would be stronger without Brendan. This is ridiculous, this is a shame, this is a scandal. A small step for a few, a giant leap back for the Web.

Who said "Mozilla Community"? Who said Openness? Pfffff. I've been a Mozillian for fourteen years and I'm not even sure I still recognize myself in today's Mozilla Community. Well done guys, well done. What's the next step? 100% political correctness? Is it still possible to have a legally valid personal opinion while being at Mozilla and express it in public?

Personal message to Brendan : Paris in April and May can be such a wonderful city. Come over here for a break, I have a few good restaurants, bars and unknown superb monuments to show you... With all my thoughts and support.

"I may disagree with what you have to say, but I shall defend, to the death, your right to say it"

(comments disallowed, I still have in mind the hate messages left on this blog last week)

Update: I perfectly understood the fact Brendan resigned because of the external pressure. But that external pressure would probably not have existed at all without the original internal pressure. Reminding Brendan's position was, I already said it, pointing an index at him. Being an employee and explicitly saying in public "I don't support Brendan as CEO because of his prop8 support" triggered the rest. That's where I don't understand the Mozilla Community any more.

http://www.glazman.org/weblog/dotclear/index.php?post/2014/04/04/Sad-day

Hey Everyone!

First some brief Background, Mozilla Releng has our code in a *lot* of repos, most being in Mercurial (a few other needs are in git or svn, but those are very rare relatively). I also do work for SeaMonkey which has needs with m-c, m-i, m-*, c-c, c-* etc. And needs with l10n…

I personally manage all my patches with MQ. Which presents a problem for me, “keeping track of it all”. I used to try keeping open bugs, but thats hard with releng because while a bug may be open, we tend to have a good handful of patches attached to it, for various repos, and they need to land in certain orders sometimes.

Other ways I’ve tried to cope have been with landing as soon as the review comes in and avoiding writing patches for parts that need to land later until the first parts are landed/deployed. I found that method encompasses unneeded end-to-end times on bugs, and unnecessary context-switching.

To curb that I wrote a mozilla-build (bash) script [in ~/.bash_profile ] that sets an alias `patchset` that I run, and it works!

It especially works because I keep my code in /c/Sources/hg/* some repos are multi-levels deep, so this code could/should be improved or at least edited for your uses, but without further ado, this is how I manage my patchset (again note, all my work is in Mercurial, I do convert my stuff over to git/etc as needed though):

EDIT: I forgot to give credit for my normalize_path() implemented I stole Borrowed from http://www.linuxjournal.com/content/normalizing-path-names-bash

Provided as-is, without alteration (again cleanups likely):

function normalize_path()
{
    # Remove all /./ sequences.
    local   path=${1//\/.\//\/}

    # Remove first dir/.. sequence.
    local   npath=$(echo $path | sed -e 's;[^/][^/]*/\.\./;;')

    # Remove remaining dir/.. sequence.
    while [[ $npath != $path ]]
    do
        path=$npath
        npath=$(echo $path | sed -e 's;[^/][^/]*/\.\./;;')
    done
    path=$npath
    npath=$(echo $path | sed -e 's;[^/][^/]*/\.\.$;;')
    echo $npath
}

function patchset() {
    pushd /c/Sources/hg >/dev/null
    for i in `find . -maxdepth 2 ! \( -name l10n -prune \) -a -name .hg`;
      do
        pushd $i/.. >/dev/null;
        if [ `hg --config color.mode=auto qseries | wc -l` != 0 ]; then
            echo -n "======= "; echo -n $(normalize_path $i/..); echo " =====";
            hg qseries;
        fi
        popd >/dev/null;
    done
    for i in `find ./users -maxdepth 3 -name .hg`;
      do
        pushd $i/.. >/dev/null;
        if [ `hg --config color.mode=auto qseries | wc -l` != 0 ]; then
            echo -n "======= "; echo -n $(normalize_path $i/..); echo " =====";
            hg qseries;
        fi
        popd >/dev/null;
    done
    for i in `find ./l10n -maxdepth 3 -name .hg`;
      do
        pushd $i/.. >/dev/null;
        if [ `hg --config color.mode=auto qseries | wc -l` != 0 ]; then
            echo -n "======= "; echo -n $(normalize_path $i/..); echo " =====";
            hg qseries;
        fi
        popd >/dev/null;
    done
    popd >/dev/null
}

And the output of that, as it stands for me _today_:

Justin@AQUARIUS /c/Sources/hg/mozharness
$ patchset
======= ./braindump/ =====
seamonkey-bouncer
======= ./buildbot-configs/ =====
ionmonkey
======= ./buildbotcustom/ =====
ionmonkey
======= ./mozharness/ =====
ionmonkey
======= ./slaveapi/ =====
timestamp
docs

Lastly my qty of repos:

$ pushd /c/Sources/hg
/c/Sources/hg /c/Sources/hg/mozharness

Justin@AQUARIUS /c/Sources/hg
$ find . -maxdepth 2 ! \( -name l10n -prune \) -a -name .hg | wc -l
17

Justin@AQUARIUS /c/Sources/hg
$ find ./users -maxdepth 3 -name .hg | wc -l
19

Justin@AQUARIUS /c/Sources/hg
$ find ./l10n -maxdepth 3 -name .hg | wc -l
52

Hope this helps!

http://blog.drapostles.org/archives/126

Slides for the brief talk that I gave at a Harvard seminar on privacy and user data organized by John Taysom last week.

My talk was really more about the “network problem” than the “protocol problem”. Networks breed first- and second-mover winners and others path-dependent powers, until the next disruption. Users or rather their data get captured.

Privacy is only one concern among several, including how to realize economic value for many-yet-individually-weak users, not just for data-store/service owners or third parties. Can we do better with client-side and private-cloud tiers, zero-knowledge proofs and protocols, or other ideas?

In the end, I asked these four questions:

1. Can a browser/OS “unionize its users” to gain bargaining power vs. net super-powers?
2. To create a data commons with “API to me” and aggregated/clustered economics?
3. Open the walled gardens to put users first?
4. Still be usable and private-enough for most?

I think the answer is yes, but I’m not sure who will do this work. It is vitally important.

I may get to it, but not working at Mozilla. I’ve resigned as CEO and I’m leaving Mozilla to take a rest, take some trips with my family, look at problems from other angles, and see if the “network problem” has a solution that doesn’t require scaling up to hundreds of millions of users and winning their trust while somehow covering costs. That’s a rare, hard thing, which I’m proud to have done with Firefox at Mozilla.

I encourage all Mozillians to keep going. Firefox OS is even more daunting, and more important. Thanks indeed to all who have supported me, and to all my colleagues over the years, at Mozilla, in standards bodies, and at conferences around the world. I will be less visible online, but still around.

/be

https://brendaneich.com/2014/04/the-next-mission/

I’m delighted to welcome Rosana Ardila as Program Manager for Mozilla Reps. Rosana has moved from the SUMO team where she has worked hard building up a strong community there. She helped build out contributor tools, a buddy program, and more to make it one of the strongest groups in Mozilla in terms of participation. Read how her former team holds her in high regard. Rosana has many skills apart from community building, including being able to speak six languages fluently which is a great asset in a global organisation like Mozilla.

Rosana (picture by Pierros Papadeas)

Rosana’s role in Reps will be to help the program evolve to meet the new challenges that constantly arise at Mozilla. She will assist in defining strategies to grow and develop the program, including a robust leadership structure, and measure its impact on community health and organizational goals. For example for our 2014 goal of scaling our contributor base by 10x, Reps can have a crucial role in this. Rosana will also be hands-on in some day to day work ensuring that the processes and documentation we’ve put in place continue to serve effectively.

My role has evolved to oversee a few of the programs in Contributor Engagement (another post to follow on that), but I will still be working very closely with Rosana in Reps.

Oh, and Long Live The Queen! (fun)

Related articles

• Community growth in 2013: we’re ready for 2014
• Reps Leads Meetup Summary

http://brian.kingsonline.net/talk/2014/04/welcome-rosana-to-reps/

This discussion took place three years ago, and we have been working very hard to make it happen. But we are now done: Bugzilla 5.0, the next major release of Bugzilla which will be released later this month on April 31, will be based on Python 3.4, meaning that Bugzilla 4.4 was the last major release to be based on Perl. We hope this migration to Python will trigger more contributors and will increase the development rate of Bugzilla.

Bugzilla 5.0 comes with many major changes. Just to name a few:

• Support for Internet Explorer (including IE 11) and less known browsers has been removed. You must now run Firefox, Google Chrome or Safari, which fully support HTML5, else an error message will be displayed asking you to use one of these browsers.
• You must have Java 8 installed and enabled in your browser in order to upload new attachments. This way, sanity checks can be done client-side before the attachment is uploaded to Bugzilla. If you don’t have Java installed or enabled, you can still view existing attachments, though, but you won’t be able to upload new ones.
• The version 5.0 of Bugzilla can be downloaded for free, but security fixes (5.0.1, 5.0.2, …) require that you register to our server to be able to download them. The fee isn’t expensive: $20 per security release for installations with less than 10 users. $200 between 10 and 50 users. $1000 above 50 users. As we do security releases only once every 4 months or so, this means that you can keep your installation safe for only $60 per year (or $3000 for larger installations).
• For other changes, please read the Bugzilla 5.0 release notes.

Enjoy!

http://lpsolit.wordpress.com/2014/04/01/bugzilla-5-0-moved-to-python-bye-bye-perl/

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

• [880113] Use the cache for the product and component name
• [988744] orangefactor template_before_process should check $file before checking user settings
• [989415] Weird “0 of attachment” text in bugmail from patches attached to security bugs
• [987741] deleted comment checking runs before tags are preloaded, triggering excessive database queries
• [989650] Allow requestees to set attachment flags even if they don’t have editbugs privs
• [990070] Bug.update_attachment should allow for adding a comment when updating attachment details similar to attachment.cgi
• [989633] Unable to change content type using Bug.update_attachment if attachment previously set to is_patch = 1
• [774198] “Undefined subroutine Fh::slice” while attaching a file

discuss these changes on mozilla.tools.bmo.

http://globau.wordpress.com/2014/04/01/happy-bmo-push-day-88/

http://www.twobraids.com/2014/03/the-mozilla-ceo.html

I would not vote for Brendan if he were running for president. However I fully support him as CEO of Mozilla.

Why the difference? Simply because as Mozilla's CEO, his personal views on LGBT (at least what one can infer from monetary support to Prop 8) do not have any measurable chance of making any difference in what Mozilla does or Mozilla's mission. It's not like we're going to ship Firefox OS phones to everybody... except LGBT individuals. There's a zero chance of that happening.

From what I've read so far (and I would love to be corrected) it seems like people who are asking Brendan to step down are doing so as a matter of principle rather than a matter of possible consequence. They feel very strongly about LGBT equality, and rightly so. And therefore they do not want to see any person who is at all opposed to that cause take any position of power, as a general principle. This totally makes sense, and given two CEO candidates who are identical except for their views on LGBT issues, I too would pick the pro-LGBT one.

But that's not the situation we have. I don't know who the other CEO candidates are or were, but I can say with confidence that there's nobody else in the world who can match Brendan in some areas that are very relevant to Mozilla's mission. I don't know exactly what qualities we need in a CEO right now but I'm pretty sure that dedication and commitment to Mozilla's mission, as well as technical expertise, are going to be pretty high on that list. That's why I support Brendan as CEO despite his views.

If you're reading this, you are probably a strong supporter of Mozilla's mission. If you don't want Brendan as CEO because of his views, it's because you are being forced into making a tough choice - you have to choose between the "open web" affiliation on your personal identity and the "LGBT" affiliation on your personal identity. That's a hard choice for anybody, and I don't think anybody can fault you regardless of what you choose.

If you choose to go further and boycott Mozilla and Mozilla's products because of the CEO's views, you have a right to do that too. However I would like to understand how you think this will help with either the open web or LGBT rights. I believe that switching from Firefox to Chrome will not change Brendan or anybody else's views on LGBT rights, and will actively harm the open web. The only winner there is Google's revenue stream. If you disagree with this I would love to know why. You may wish to boycott Mozilla products as a matter of principle, and I can't argue with that. But please make sure that the benefit you gain from doing so outweighs the cost.

https://staktrace.com/spout/entry.php?id=823

Seneca College Library Image ©moqub,  https://flic.kr/p/9PyVVm Creative Commons by-nc-sa 2.0

http://relengofthenerds.blogspot.com/2014/03/schooling-yourself-in-release.html

In order to improve the feedback and the beta releases of Firefox, we are going to start publishing some information on beta releases.
For this, we are using the mercurial repository and using these two tags/revisions: --rev "ancestor(FIREFOX_29_0b2_RELEASE,FIREFOX_29_0b3_RELEASE)::FIREFOX_29_0b3_RELEASE" (See bsmedberg's blog post for more information on this syntax).

We are ignoring the commit from the ffxbld robot.

Firefox 29 beta 3 release(compared to Firefox 29 beta 2)
Here are some numbers:

• 49 changesets
• 112 files changed
• 2174 insertions
• 423 deletions

List of changes:
Philipp Sackl: Bug 979938 - Delay the display of the tab close button to avoid visual noise. r=Dao, a=sylvestre
Masayuki Nakano: Bug 981963 Ignore following char message if its wParam is 0 r=jimm, a=sledru
JW Wang: Bug 907162 - Fix MediaDecoderStateMachine might dispatch MediaDecoder::PlaybackEnded more than once and trigger multiple 'ended' events in HTMLMediaElement. r=cpearce, a=sledru
JW Wang: Bug 934794 - Fix failing to update stream blocking status when endBlockingDecisions == mStateComputedTime. r=roc, a=sledru
Olli Pettay: Bug 985988 = Event handlers should update preventDefault flag similar way to event.preventDefault(). r=masayuki, a=sledru
Brandon Benvie: Bug 970172 - Prevent VariablesView Variables from handling clicks while editing. r=vporof, a=sledru
Brian Nicholson: Bug 962103 - Make progress bar overlap content. r=lucasr, a=sledru
Brian Nicholson: Bug 962103 - Fix progress bar visibility on pre-Honeycomb devices. r=lucasr, a=sledru
John Schoenick: Bug 985859 - navigator.mimeTypes access should be case-insensitive. r=bsmedberg, a=sledru
Sebastian Hengst: Bug 982615 - Sync panel is not entirely displayed in localized builds. r=mak, a=gavin
Bobby Holley: Bug 986542 - Don't categorically disable script for detached docshells. r=bz, a=sledru
Gavin Sharp: Bug 955950 - Add pref to disable "reset Firefox" nag. r=MattN, a=sledru
Ryan VanderMeulen: Bug 985859 - Adding missing include to fix bustage. a=bustage
Shane Caraveo: Bug 915835 fix leak in socialmarks event listeners, r=markh, a=lsblakk
Chris Karlof: Bug 983256 - Change the client generated expiration time in FxA assertions to be 'forever'. r=jedp, a=lsblakk
Shane Caraveo: Bug 984628 fix social button states, r=markh, a=sylvestre
Nathan Froyd: Bug 942411 - Set the src of the iframe after adding it to the document. a=test-only
Phil Ringnalda: Bug 863658 - Replace mozilla-banner.gif with a plain blue image in 359903-2.html since we aren't trying to test individual pixel differences in resized image painting there. r=bz, a=test-only
Ryan VanderMeulen: Bug 948389 - Replace mozilla-banner.gif with a plain blue image in 405577-1.html since we aren't trying to test individual pixel differences in resized image painting there. r=roc, a=test-only
Brian Grinstead: Bug 962931 - Request longer timeout for browser_webconsole_split.js. r=msucan, a=test-only
Brian R. Bondy: Bug 981166 - Turn off Metro Firefox and cleanup DEH registration. r=rstrong, jimm. a=sylvestre
Nicholas Hurley: Bug 978759 - Fix shutdown crash in seer. r=mcmanus, a=sledru
Margaret Leibovic: Bug 943262 - Use CharsetMenu.jsm instead of charsetTitles.properties for Character Encoding menu items. r=bnicholson, a=sledru
Sid Stamm: Bug 835357 - Fix telemetry probes for DNT so they accumulate before the pings are sent. r=mcmanus, a=sledru
Ryan VanderMeulen: Backed out the requestCompleteLog part of Bug 942411 because it wasn't needed for the fix anyway. a=bustage
Brian Smith :: Return the correct error message when no potential issuers are found during path bulding in insanity::pkix, r=keeler a=sylvestre
Brian Smith: Bug 978120, Part 1: Make nsIX509Cert.setCerttrust, and nsIX509CertDB.addCert, and nsIX509CertDB2.addCertFromBase64 work on Android and B2G, r=keeler a=sylvestre
Brian Smith :: part 2: Enable more PSM xpcshell tests on Android and B2G, r=keeler a=testonly
Margaret Leibovic: Bug 982181 - Hide home banner after it is animated off screen, to avoid intercepting click events on pre-honeycomb devices. r=lucasr a=sledru
Ryan VanderMeulen: Backed out changesets d3352d36dbdf and e74b6a1da573 (Bug 978120) and changeset 816c209eaa71 (Bug 978528) for Android xpcshell failures.
Monica Chew :: Force url classifier clients to specify which tables to lookup, add a pref to skip hash completion checks (r=gcp,ba=sledru)
Matthew Noorenberghe: Bug 985786 - [10.6] Make the button to leave fullscreen match the styles of other toolbarbuttons and fix its missing image. r=mconley a=Sylvestre
Marco Bonardo: Bug 983571 - browser.bookmarks.autoExportHTML = true no longer works. r=Yoric a=sylvestre
Marco Bonardo: Backout 450a302d1ffa (Bug 983571) due to xpcshell failures
Monica Chew :: Rename urlclassifier.download_block_table and urlclassifier.download_allow_table (r=gcp,a=sledru)
Marco Bonardo: Bug 983571 - browser.bookmarks.autoExportHTML = true no longer works. r=Yoric a=sylvestre
Masatoshi Kimura: Bug 986347 - Restore accidentaly removed HasBogusPopupsDropShadowOnMultiMonitor() call. r=jimm a=sylvestre
Mike de Boer :: restore sidebar splitter and header styles on Windows 8. r=jaws, a=sledru.
Mike Conley: Bug 984156 - Make subview footer menuseparators have a non-zero height to prevent bookmarks folder scrolling issues. r=mak, a=sledru.
Gijs Kruitbosch: Bug 986529 - invert tab close icons on windows classic, r=jaws, a=sledru.
Tim Nguyen: Bug 984979 - Fix back button :active state on Windows 8, r=gijs, a=sledru.
Gijs Kruitbosch: Bug 985815 - fix customtoolbars test so it doesn't break subsequent tests, r=jaws, a=sledru.
Gijs Kruitbosch: Bug 985815 - propagate collapsed state to other windows, add test. r=jaws, a=sledru.
Gijs Kruitbosch: Bug 987615 - fix layout of buttons which are too long in customize mode, r=jaws, a=sledru.
Steven MacLeod: Bug 967028 - Use a SHistoryListener to collect entries from history.pushState(). r=Yoric, a=sylvestre
Jonathan Watt: Bug 959128 - Fix transforms of clipPath content for clipPath being used within SVG-in-OpenType glyph. r=heycam, a=sylvestre
Brian R. Bondy: Backout 7971f738a6cd temporarily as a safety precaution. r=jimm, rsrong, me. a=me
Ehsan Akhgari: Backed out 2 changesets (Bug 957652) because Bug 957431 is being backed out, a=sylvestre
Ehsan Akhgari: Backed out 2 changesets (Bug 957431) because we decided we're keeping Attr.ownerElement in the end; a=sylvestre ba=me
r= means reviewed by
a= means uplift approved by

If you have any suggestion to improve this for the next report, don't hesitate!

http://sylvestre.ledru.info/blog/2014/03/31/changes-firefox-29-beta2-to

You can now add accounts from three popular Mozilla sites to your profile on mozilllians.org, our community directory. This changes adds support for wiki.mozilla.org, webmaker.org and reps.mozilla.org accounts. Simply sign-in to Edit Your Profile, and then fill in the accounts you want to add. You can choose to make those accounts publicly viewable or only show them to other vouched Mozillians.

You can now add accounts from three popular Mozilla sites to your mozillians.org profile

And while you are updating your profile, be sure to add your timezone. This is especially helpful for finding good times to chat with others who are in different time zones.

http://dailycavalier.com/2014/03/add-more-accounts-to-your-mozillians-org-profile/

http://inpursuitoflaziness.blogspot.com/2014/01/editing-files-from-omnija-in-firefox-20.html

Last week I wrote that Mozilla’s commitment to inclusiveness for our LGBT community, and for all underrepresented groups, will not change. Acting for or on behalf of Mozilla, it is unacceptable to limit opportunity for *anyone* based on the nature of sexual orientation and/or gender identity. This is not only a commitment, it is our identity.

This left unanswered the question of whether equality explicitly includes marital equality. I want to clear that up. Speaking as the Chairwoman, I want to speak clearly on behalf of both the Mozilla Corporation and the Mozilla Foundation: Mozilla supports equality for all, explicitly including LGBT equality and marriage equality.

Statement: Mozilla Supports Marriage Equality

https://blog.lizardwrangler.com/2014/03/29/on-mozillas-support-for-marriage-equality/

Every once or twice in a 4 month term, I get a sudden rush of inspiration and ideas for cool things to take on as projects. This term at Mozilla there has been a lot of exposure with open sourcing, scraping the web for data and software tooling and automation. This lapse of ideas mostly revolve around those areas.

However, I usually get drained after the phase is done which is probably why I don’t feel like doing anything right now. I’ve already created repositories for these projects on GitHub and will contribute to whichever then interests me the most after this lazy phase is done.

1. Tradester

“Wouldn’t it be awesome to have a financial trading algorithm that anyone can write into and use freely?”. This thought came to me a few years ago when I finished first year at university. I wanted to start an open sourced script for an automated trading algorithm. The hope was for it to encompass all the smartness of traders everywhere into one algorithm for all who are smart enough to take advantage of it. Then I found MetaTrader4, a niche language which I never found the willpower to learn. So the idea died, or in terms of recent medical research, got put in animated suspension.



Recently, I discovered that online brokers like Oanda and Robinhood (hopefully soon) are starting to offer REST APIs as one of their services to traders. Then it hit me that MT4 could be dropped completely by using common scripting languages like PHP instead. I.e. deploy algorithm script on any web hosting service, set-up CRON jobs, start automated trading. It also helps that web development languages are more popular than the obscure MT4, which is important considering that this will be open sourced.

2. StoryLine

This started about a year ago. The idea was for a common social platform where story writers could come together and collaboratively create new stories that were open sourced, like the GitHub for people who wrote in languages that were not meant for the computer.



The project died mid-way when I realized that the product was taking a very bad approach to begin. It was made to try and take on a lot of stories and writers at the same time, which led to a very confusing user experience because of all the empty “social” views. I was working through the version control (back-end) component of StoryLine and Terry on the user interfaces when the project was killed.

I recently found inspiration from looking at the WordPress model. The code is open sourced, so anyone can deploy and install their own independent instance of WordPress. At the same time, non-technical users can simply use wordpress.com where deployment is made simple. WordPress makes money from advertising on the wordpress.com sites and from writers who wish to export wordpress.com sites to their own hosting servers.

Instead of a common platform that acts as GitHub for writers, StoryLine is likely to be better off as a deployable web application for all end-users. Each instance of StoryLine hosts a single, independent story. At some point later after maturity, a unified tool for users to create stories easily on awesome-name.storyline.com can be set up, much like the existing wordpress.com.

3. Languify

I love fontawesome. It’s open sourced, so simple, and adds so much value when used in the right context. Languify, like fontawesome, is an open sourced CSS library that contains commonly used words and phrases in different languages. Languify enables developers to create views that can be adapted to any language they want, just by the loading of a .css file.

For example,

http://blog.williecheong.com/ideas-for-web-applications/

There’s been something of an uproar over Brendan Eich’s promotion to the role of CEO of Mozilla Corporation due to the fact that many years ago, he donated money to support Proposition 8 in California. I’m not going to link to any of the blog posts, tweets, or news stories about this, since I don’t really want to give more traffic to rumormongers, especially since a lot of the stories are mostly speculation.

Since I work for Mozilla, I obviously have opinions on this. I’m going to share them, but first I’m going to be sure to point out what I’m not:

• I’ve never reported to Brendan either directly or indirectly.
• I’m not gay, so his opinions in the area don’t directly affect me.

With that out of the way, let me say this: in the more than eight years I’ve worked at Mozilla, I’ve never known Brendan to treat anyone differently based on their gender, sexual orientation, color, religion, eye color, height, weight, or anything else (sorry for being slightly flippant there; it’s how I handle this stuff).

I felt then, and feel now, that Prop 8 is a mistake, is unconstitutional, and is a moral catastrophe. Freedom to marry the consenting adult of your dreams is a core human right and should be protected as such. Now with my feelings on the matter exposed, let’s press on.

While I, too, would like him to make a statement clarifying things further, I also don’t think it’s any of my business. As long as Brendan’s feelings don’t impact his work functions, I honestly don’t care what he thinks. As far as I can tell, all he cares about is whether or not you can deliver the goods when you’re working on the project. That’s all that matters to me.

He can be cranky and dismissive at times when he thinks you’re wrong (or less right than he is), but everyone can be that way (I know I can). Whatever his personal feelings are on gay marriage (or homosexuality in general, or anything else), Brendan is a brilliant developer and manager, a great leader, and an avid supporter of open source software and of the free and open Web. In those respects, he’s the best possible person for the job of CEO of Mozilla.

Mozillians are a diverse community. Brendan knows that; he’s known that since he first helped create Mozilla a decade and a half ago. He’s never once been involved in controversy related to that diversity; becoming CEO doesn’t, I think, make him any more likely to be so.

Let’s give him the benefit of the doubt, and get back to rockin’ the open Web.

http://www.bitstampede.com/2014/03/29/on-brendan-eich-as-ceo-of-mozilla/

[Attention conservation notice: probably not of interest to lawyers; this is about my previous life in software development.]

/commons.wikimedia.org/wiki/File:MW_Bug_Squad_Barnstar.svg">Bugsquad barnstar, under MPL 1.1" class="size-full wp-image-2683 " height="194" src="http://lu.is/blog/wp-content/uploads/2014/03/MW_Bug_Squad_Barnstar.png" width="200" />

Bugsquad barnstar, under MPL 1.1

Someone recently mentioned JWZ’s old post on the CADT (Cascade of Attention Deficit Teecnagers) development model, and that finally has pushed me to say:

I am the CADT.

I did the bug closure that triggered Jamie’s rant, and I wrote the text he quotes in his blog post.¹

Jamie got some things right, and some things wrong. The main thing he got right is that it is entirely possible to get into a cycle where instead of seriously trying to fix bugs, you just do a rewrite and cross your fingers that it fixes old bugs. And yes, this can particularly happen when you’re young and writing code for fun, where the joy of a from-scratch rewrite can overwhelm some of your other good senses. Jamie also got right that I communicated the issue pretty poorly. Consider this post a belated explanation (as well as a reference for the next time I see someone refer to CADT).

But that wasn’t what GNOME was doing when Jamie complained about it, and I doubt it is actually something that happens very often in any project large enough to have a large bug tracking system (BTS). So what were we doing?

First, as Brendan Eich has pointed out, sometimes a rewrite really is a good idea. GNOME 2 was such a rewrite – not only was a lot of the old code a hairy mess, we decided (correctly) to radically revise the old UI. So in that sense, the rewrite was not a “CADT” decision – the core bugs being fixed were the kinds of bugs that could only be fixed with massive, non-incremental change, rather than “hey, we got bored with the old code”. (Immediately afterwards, GNOME switched to time-based releases, and stuck to that schedule for the better part of a decade, which should be further proof we weren’t cascading.)

This meant there were several thousand old bugs that had been filed against UIs that no longer existed, and often against code that no longer existed or had been radically rewritten. So you’ve got new code and old bugs. What do you do with the old bugs?

It is important to know that open bugs in a BTS are not free. Old bugs impose a cost on developers, because when they are trying to search relevant bugs, old bugs can make it harder to find the things they really should be working on. In the best case, this slows them down; in the worst case, it drives them to use other tools to track the work they want to do – making the BTS next to useless. This violates rule #1 of a BTS: it must be useful for developers, or else it all falls apart.

So why did we choose to reduce these costs by closing bugs filed against the old codebase as NEEDINFO (and asking people to reopen if they were still relevant) instead of re-testing and re-triaging them one-by-one, as Jamie would have suggested? A few reasons:

• number of triagers v. number of bugs: there were, at the time, around a half-dozen active bug volunteers, and thousands of pre-GNOME 2 bugs. It was simply unlikely that we’d ever be able to review all the old bugs even if we did nothing else.
• focus on new bugs: new bugs are where triagers and developers are much more likely to be relevant – those bugs are against fresh code; the original filer is much more likely to respond to clarifying questions; etc. So all else being equal, time spent on new bugs was going to be much better for the software than time spent on old bugs.
• steady flow of new bugs: if you’ve got a small number of new bugs coming in, perhaps you split your time – but we had no shortage of new bugs, nor of motivated bug reporters. So we may have paid some cost (by demotivating some reporters) but our scarce resource (developers) greatly appreciated it.
• relative burden: with thousands of open bugs from thousands of reporters, it made sense to ask old them to test their bug against the new code. Reviewing their old bugs was a small burden for each of them, once we distributed it.

So when isn’t it a good idea to close ask for more information about old bugs?

• Great at keeping old bugs triaged/relevant: If you have a very small number of old bugs that haven’t been touched in a long time, then they aren’t putting much burden on developers.
• Slow code turnover: If your development process is such that it is highly likely that old bugs are still relevant (e.g., core has remained mostly untouched for many years, or effective use of TDD has kept the number of accidental new bugs low) this might not be a good idea.
• No triggering event: In GNOME, there was a big event, plus a new influx of triagers, that made it make sense to do radical change. I wouldn’t recommend this “just because” – it should go hand-in-hand with other large changes, like a major release or important policy changes that will make future triaging more effective.

Relatedly, the team practices mailing list has been discussing good practices for migrating bug tracking systems in the past few days, which has been interesting to follow. I don’t take a strong position on where Wikimedia’s bugzilla falls on this point – Mediawiki has a fairly stable core, and the volume of incoming bugs may make triage of old bugs more plausible. But everyone running a very large bugzilla for an active project should remember that this is a part of their toolkit.

1. Both had help from others, but it was eventually my decision.

http://lu.is/blog/2014/03/28/i-am-the-cadt-and-advice-on-needinfoing-old-bugs-en-masse/

http://home.kairo.at/blog/2014-03/lantea_maps_conversion_to_webgl

let greeter = {
  message: "Hello, NAME!",
  greet: function(name) {
    return Task.spawn((function*() {
      return yield sendGreeting(this.message.replace(/NAME/, name));
    }).bind(this);
  })
};

let greeter = {
  message: "Hello, NAME!",
  greet: Task.async(function*(name) {
    return yield sendGreeting(this.message.replace(/NAME/, name));
  })
};

greeter.greet("Mitchell").then((reply) => { ... }); // behaves the same

http://mykzilla.blogspot.com/2014/03/simplify-asynchronous-method.html

For a while now, when people ask me how they can improve their websites’ security, I tell them: Start by turning on HTTPS for everything. Run a separate server on port 80 that issues nothing but permanent redirects to the https:// version of the same URL. There’s lots more you can do, but that’s the easy first step. There are a number of common objections to this plan; today I want to talk about the “it should be the user’s choice” objection, expressed for instance in “Google to Gmail customers: You WILL use HTTPS” by Robert Mitchell. It goes something like this:

Why should I (the operator of the website) assume I know better than each of my users what their security posture should be? Maybe this is a “throwaway” account, of no great importance to them. Maybe they are on a slow link that is intrinsically hard to eavesdrop upon, so the extra network round-trips involved in setting up a secure channel make the site annoyingly slow for no benefit.

This objection ignores the “public health” benefits of secure channels. I’d like to make an analogy to immunization, here. If you get vaccinated against the measles (for instance), that’s good for you because you are much less likely to get the disease yourself. But it is also good for everyone who lives near you, because now you can’t infect them either. If enough people in a region are immune, then nobody will get the disease, even if they aren’t immune; this is called herd immunity. Secure channels have similar benefits to the general public—unconditionally securing a website improves security for everyone on the ‘net, whether or not they use that website! Here’s why.

Most of the criminals who “crack” websites don’t care which accounts they gain access to. This surprises people; if you ask users, they often say things like “well, nobody would bother breaking into my email / bank account / personal computer, because I’m not a celebrity and I don’t have any money!” But the attackers don’t care about that. They break into email accounts so they can send spam; any @gmail.com address is as good as any other. They break into bank accounts so they can commit credit card fraud; any given person’s card is probably only good for US$1000 or so, but multiply that by thousands of cards and you’re talking about real money. They break into PCs so they can run botnets; they don’t care about data stored on the computer, they want the CPU and the network connection. For more on this point, see the paper “Folk Models of Home Computer Security” by Rick Wash. This is the most important reason why security needs to be unconditional. Accounts may be “throwaway” to their users, but they are all the same to the attackers.

Often, criminals who “crack” websites don’t care which websites they gain access to, either. The logic is similar: the legitimate contents of the website are irrelevant. All the attacker wants is to reuse a legitimate site as part of a spamming scheme or to copy the user list, guess the weaker passwords, and try those username+password combinations on “more important” websites. This is why everyone who has a website, even if it’s tiny and attracts hardly any traffic, needs to worry about its security. This is also why making websites secure improves security for everyone, even if they never intentionally visit that website.

Now, how does HTTPS help with all this? The easiest several ways to break into websites involve snooping on unsecured network traffic to steal user credentials. This is possible even with the common-but-insufficient tactic of sending only the login form over HTTPS, because every insecure HTTP request after login includes a piece of data called a “session cookie” that can be stolen and used to impersonate the user for most purposes without having to know the user’s password. (It’s often not possible to change the user’s password without also knowing the old password, but that’s about it. If an attacker just wants to send spam, and doesn’t care about maintaining control of the account, a session cookie is good enough.) It’s also possible even if all logged-in users are served only HTTPS, but you get an unsecured page until you login, because then an attacker can modify the unsecured page and make it steal credentials. Only applying channel security to the entire site for everyone, whoever they are, logged in or not, makes this class of attacks go away.

Unconditional use of HTTPS also enables further security improvements. For instance, a site that is exclusively HTTPS can use the Strict-Transport-Security mechanism to put browsers on notice that they should never communicate with it over an insecure channel: this is important because there are turnkey “SSL stripping” tools that lurk in between a legitimate site and a targeted user and make it look like the site wasn’t HTTPS in the first place. There are subtle differences in the browser’s presentation that a clever human might notice—or you could direct the computer to pay attention, and then it will notice. But this only works, again, if the site is always HTTPS for everyone. Similarly, an always-secured site can mark all of its cookies “secure” and “httponly” which cuts off more ways for attackers to steal user credentials. And if a site runs complicated code on the server, exposing that code to the public Internet two different ways (HTTP and HTTPS) enlarges the server’s attack surface. If the only thing on port 80 is a boilerplate “try again with HTTPS” permanent redirect, this is not an issue. (Bonus points for invalidating session cookies and passwords that just went over the wire in cleartext.)

Finally, I’ll mention that if a site’s users can turn security off, then there’s a per-user toggle switch in the site’s memory banks somewhere, and the site operators can flip that switch off if they want. Or if they have been, shall we say, leaned on. It’s a lot easier for the site operators to stand up to being leaned on if they can say “that’s not a thing our code can do.”

https://www.owlfolio.org/research/security-is-like-immunization/