http://bluesock.org/~willkg/blog/mozilla/input_status_20140912

(this is originally a comment on the post about “scientific Markdown”)

In my previous life I was using heavily TeX and BibTeX for writing a scholarly articles when working on my PhD in sociology. When doing a large BibTeX database of bibliopgraphy there is a certain moment when one needs to establish some order in creating new keys for the individual references. When I hit that moment, I started to look around whether somebody didn’t do some thinking about the design of the bibliography keys. I found almost nothing on the Web perhaps because there was actually a file bibshare (originally in $TEXMF/doc/bibtex/base/bibshare now I cannot find it anywhere, so I have download a version from older tetex RPM to my website). It describes pretty nice standard, which really should be rewritten into RFC or something of that sort. The two biggest advantages are stable keys (so bibliographies can be exchanged) and a more rememberable ones. So, whenever I see now granovetter:AJS-1973-1360 I do remember (and it has been couple of years, since I used BibTeX last time) that it is an awesome article "The Strength of Weak Ties" by Mark Granovetter.

https://luther.ceplovi.cz/blog/2014/09/12/on-bibshare/

I recently returned from Istanbul, Turkey where I attended the 9th annual Internet Governance Forum. This was my third IGF in a row, and my second with Mozilla. Like the others I’ve attended, it was a vibrant event, with over 3000 registrants from very different regions and interests culminating in an energizing, inspiring forum.

This year’s event reinforced my positive position on the IGF. It has a crucial role to play at the core of the Internet governance ecosystem, and it continues to fulfill that role far, far better than any other event. The IGF brings people from all walks of life into the same venue and it gets them to interact with each other and talk about difficult issues, face to face and in real time. This year, even remote participation worked fairly smoothly, as I attended a couple sessions that included speakers on video-conference connections.

Some viewed Turkey as an odd choice for a host, given the country’s history of social media blocking and other interference with free expression and activity online (including a law adopted just after the conclusion of IGF to make it even easier to block Web pages). The sentiment was strong enough to inspire the creation of a competing “Internet Ungovernance Forum” focused on promoting an open, secure, and free-as-in-speech Internet. Despite the undercurrents, both forums were well attended, and featured a broad range of interesting and expert speakers (and even some who were both!).

There is always a spotlight on IGF in the international Internet policy world. This year’s comes from NETmundial in Brazil, and, looking ahead a bit, this October’s ITU Plenipotentiary Conference in Korea, a once-every-four-years convening for high-level intergovernmental activity at the core of the ITU’s mission.

So, what did that spotlight illuminate? As always, there were many broad-ranging discussions on Internet policy issues, and no structural mechanisms to move from policy development to any formalized decision-making. (But for the IGF, this is a feature, not a bug.)

Topically, if last year was the Snowden/surveillance IGF, this year was the net neutrality IGF, with at least three feeder sessions and a three-hour “main session” focused on the topic. I spoke at two of the net neutrality sessions, and attended the others. One of my sessions examined “network enhancement” and its relationship to net neutrality – a timely topic here in the United States, where opponents of strong net neutrality rules often indicate that excessive regulation will discourage investment in infrastructure. The other was the annual working session of the Dynamic Coalition on Network Neutrality, which was praised by conference organizers as one of the most effective examples of the ad-hoc IGF working coalitions. I also contributed a paper to the Coalition’s second annual report, drawing from Mozilla’s petition to the FCC and our July comments.

Surveillance had its moments in the spotlight as well, though it was less emphasized than last year. I spoke on two surveillance-related panels. A session organized by CIGI went straight to one of our core policy themes, trust, and how revelations of expansive surveillance have harmed trust, and what we can do to restore it. A separate session, co-organized by the Internet Society and CDT, focused on responses to surveillance, such as proposals to build additional IXPs and undersea cables, and new laws to mandate localization of data within a country. The group collectively opposed localization mandates as both unhelpful for protecting Internet users from surveillance and potentially disastrous to the global free and open Internet.

The IGF isn’t perfect. But it deserves the role it has as the first stop for collaborative discussion of issues related to governance “on” the Internet. Its mandate from the UN runs for one more year, through the 10th IGF in 2015, and then unless renewed the events will stop. But with massive support from many stakeholder groups in many regions of the world – and a host country for 2016 already lined up, by some accounts – I think the IGF will, and should, continue for many years to come.

https://blog.mozilla.org/netpolicy/2014/09/11/reflections-on-the-9th-internet-governance-forum/

http://feedproxy.google.com/~r/BenjaminKerensaDotComMozilla/~3/NaRgaKYdXWg/off-to-berlin

Over the past two weeks, I’ve been working a bit on the Treeherder front end (our interface to managing build and test jobs from mercurial changesets), trying to help get things in shape so that the sheriffs can feel comfortable transitioning to it from tbpl by the end of the quarter.

One thing that has pleasantly surprised me is just how easy it’s been to get going and be productive. The process looks like this on Linux or Mac:


git clone https://github.com/mozilla/treeherder-ui.git
cd treeherder-ui/webapp
./scripts/web-server.js


Then just load http://localhost:8000 in your favorite web browser (Firefox) and you should be good to go (it will load data from the actually treeherder site). If you want to make modifications to the HTML, Javascript, or CSS just go ahead and do so with your favorite editor and the changes will be immediately reflected.

We have a fair backlog of issues to get through, many of them related to the front end. If you’re interested in helping out, please have a look:

https://wiki.mozilla.org/Auto-tools/Projects/Treeherder#Bugs_.26_Project_Tracking

If nothing jumps out at you, please drop by irc.mozilla.org #treeherder and we can probably find something for you to work on. We’re most active during Pacific Time working hours.

http://wrla.ch/blog/2014/09/hacking-on-the-treeherder-front-end-refreshingly-easy/?utm_source=rss&utm_medium=rss&utm_campaign=hacking-on-the-treeherder-front-end-refreshingly-easy

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

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

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

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

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

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

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

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

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

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

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

http://bookmaniac.org/how-to-test-new-features-in-firefox-34-aurora/

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

– Karl Fogel, Producing Open Source Software

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

– Proverbs 27:6

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

• Remove the need for _dev.py config files
• Each production config had an associated _dev.py config file
• Prevented it from running in production environment
• The only way to enable the developer mode is by appending --cfg developer_config.py

1. Find the command from the log. Copy/paste it.
2. Append --cfg developer_config.py
3. Append --installer-url/--test-url with the right values

http://feedproxy.google.com/~r/armenzg_mozilla/~3/nzPjLgf2MnI/run-tbpl-jobs-locally-with-http.html

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

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

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

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

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

http://rickyrosario.com/blog/joined-mozilla-web-team/

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

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

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

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

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

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

The message read -

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

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

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

Wow!

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

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

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

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

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

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

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

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

You might think I’m crazy.

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

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

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

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

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

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

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

‘Til then.

http://prashish.me/2014/09/09/the-plan-after-mozdrive/

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

El taller fue similar a los que he dado en el pasado, con algunas mejoras gracias a las lecciones aprendidas. La charla introductoria se puede encontrar aqu'i: Introducci'on a Firefox OS. Algunas de las p'aginas no tienen mucho sentido sin la charla, pero los v'inculos son 'utiles para empezar a trabajar con Firefox OS.

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

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

Una sorpresa muy grata es que en CascoStation trabaja un artista 3D muy habilidoso, que adem'as aplica sus talentos para crear impresiones 3D con un nivel de detalle espectacular. 'El nos cre'o una figura de Firefox OS que no podr'ia haber quedado mejor.

Espero que podamos ver m'as de estos en el futuro :).

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

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

http://xulforge.com/blog/2014/09/taller-de-firefox-os-en-panama/

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

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

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

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

http://mike.kaply.com/2014/09/09/changes-to-cck2-support/

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

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

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

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

http://christianheilmann.com/2014/09/09/how-to-draft-a-speaker-information-email/

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

over and over again.

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

http://ftangftang.wordpress.com/2014/09/09/znc-and-mozilla-irc/

When companies or organizations deploy version control, they have to make many choices. One of them is how many repositories to create. Your choices are essentially a) a single, monolithic repository that holds everything b) many separate, smaller repositories that hold all the individual parts c) something in between.

The prevailing convention today (especially in the open source realm) is to create many separate and loosely coupled repositories, each repository mapping to a specific product or service. That does seem reasonable: if you were organizing files on your filesystem, you would group them by functionality or role (photos, music, documents, etc). And, version control tools are functionally filesystems. So it makes sense to draw repository boundaries at directory/role levels.

Further reinforcing the separate repository convention is the scaling behavior of our version control tools. Git, the popular tool in open source these days, doesn't scale well to very large repositories due to - among other things - not having narrow clones (fetching a subset of files). It scales well enough to the overwhelming majority of projects. But if you are a large organization generating lots of data (read: gigabytes of data over hundreds of thousands of files and commits) for version control, Git is unsuitable in its current form. Other tools (like Mercurial) don't currently fare that much better (although Mercurial has plans to tackle these scaling vectors).

Despite popular convention and even limitations in tools, companies like Google and Facebook opt to run large, monolithic repositories. Google runs Perforce. Facebook is on Mercurial, or at least is in the process of migrating to Mercurial.

Why do these companies run monolithic repositories? In Google's words:

We have a single large depot with almost all of Google's projects on it. This aids agile development and is much loved by our users, since it allows almost anyone to easily view almost any code, allows projects to share code, and allows engineers to move freely from project to project. Documentation and data is stored on the server as well as code.

So, monolithic repositories are all about moving fast and getting things done more efficiently. In other words, monolithic repositories increase developer productivity.

Furthermore, monolithic repositories are also more compatible with the ebb and flow of large organizations and large software projects. Components, features, products, and teams come and go, merge and split. The only constant is change. And if you are maintaining separate repositories that attempt to map to this ever-changing organizational topology, you are going to have a bad time. Either you'll be constantly copying, moving, merging, splitting, etc data and repositories. Or your repositories will be organized in a very non-logical and non-intuitive manner. That translates to overhead and lost productivity. I think that monolithic repositories handle the realities of large organizations much better. Big change or reorganization you want to reflect? You can make a single, atomic, history-preserving commit to move things around. I think that's much more manageable, especially when you consider the difficulty and annoyance of history-preserving changes across repositories.

Naysayers will decry monolithic repositories on principled and practical grounds.

The principled camp will say that separate repositories constitute a loosely coupled (dare I say service oriented) architecture that maps better to how software is consumed, assembled, and deployed and that erecting barriers in the form of separate repositories deliberately enforces this architecture. I agree. However, you can still maintain a loosely coupled architecture with monolithic repositories. The Subversion model of checking out a single tree from a larger repository proves this. Furthermore, I would say architecture decisions should be enforced by people (via code review, etc), not via version control repository topology. I believe this principled argument against monolithic repositories to be rather weak.

The principled camp living in the open source realm may also decry monolithic repositories as an affront to the spirit of open source. They would say that a monolithic repository creates unfairly strong ties to the organization that operates it and creates barriers to forking, etc. This may be true. But monolithic repositories don't intrinsically infringe on the basic software freedoms, organizations do. Therefore, I find this principled argument rather weak.

The practical camp will say that monolithic repositories just don't scale or aren't suitable for general audiences. These concerns are real.

Fully distributed version control systems (every commit on every machine) definitely don't scale past certain limits. Depending on your repository and user base, your scaling limits include disk space (repository data terabytes in size), bandwidth (repository data terabytes in size), filesystem (repository hundreds of thousands or millions of files), CPU and memory (operations on large repositories take too many system resources), and many heads/branches (tools like Git and Mercurial don't scale well to tens of thousands of heads/branches). These limitations with fully distributed version control are why distributed version control tools like Git and Mercurial support a partially-distributed mode that behaves more like your classical server-client model, like those employed by Subversion, Perforce, etc. Git supports shallow clone and sparse checkout. Mercurial supports shallow clone (via remotefilelog) and has planned support for narrow clone and sparse checkout in the next release or two. Of course, you can avoid the scaling limitations of distributed version control by employing a non-distributed tool, such as Subversion. Many companies continue to reach this conclusion today. However, users adapted to the distributed workflow would likely be up in arms (they would probably use tools like hg-subversion or git-svn to maintain their workflows). So, while scaling of version control can be a real concern, there are solutions and workarounds. However, they do involve falling back to a partially-distributed model.

Another concern with monolithic repositories is user access control. You inevitably have code or data that is more sensitive and want to limit who can change or even access it. Separate repositories seem to facilitate a simpler model: per-repository access control. With monolithic repositories, you have to worry about per-directory/subtree permissions, an increased risk of data leaking, etc. This concern is more real with distributed version control, as distributed data and access control aren't naturally compatible. But these issues can be resolved. And if the tooling supports it, there is only a semantic difference between managing access control between repositories versus components of a single repository.

When it comes to repository hosting conversions, I agree with Google and Facebook: I prefer monolithic repositories. When I am interacting with version control, I just want to get stuff done. I don't want to waste time dealing with multiple commands to manage multiple repositories. I don't want to waste time or expend cognitive load dealing with submodule, subrepository, or big files management. I don't want to waste time trying to find and reuse code, data, or documentation. I want everything at my fingertips, where it can be easily discovered, inspected, and used. Monolithic repositories facilitate these workflows more than separate repositories and make me more productive as a result.

Now, if only all the tools and processes we use and love would work with monolithic repositories...

http://gregoryszorc.com/blog/2014/09/09/on-monolithic-repositories

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

• [913647] Deploy YUI 3.17.2 for BMO
• [1054138] add the ability to filter on “fields containing the string”
• [1062344] contrib/reorg-tools/sync* do not clear memcached
• [1051058] Auto-CC Erica Choe into Finance Review and Master Kick-Off Bugs

discuss these changes on mozilla.tools.bmo.

the new bugmail filtering ability allows you to filter on specific flags:

these two rules will prevent bugzilla from emaling you the changes to the “qa whiteboard” field or the “qe-verify” flag for bugs where you aren’t the assignee.

http://globau.wordpress.com/2014/09/09/happy-bmo-push-day-112/

This is the latest in a series of articles about writing a simple HTML rendering engine:

• Part 1: Getting started
• Part 2: HTML
• Part 3: CSS
• Part 4: Style
• Part 5: Boxes

This article will begin the layout module, which takes the style tree and translates it into a bunch of rectangles in a two-dimensional space. This is a big module, so I’m going to split it into several articles. Also, some of the code I share in this article may need to change as I write the code for the later parts.

The layout module’s input is the style tree from Part 4, and its output is yet another tree, the layout tree. This takes us one step further in our mini rendering pipeline:

I’ll start by talking about the basic HTML/CSS layout model. If you’ve ever learned to develop web pages you might be familiar with this already—but it may look a bit different from the implementer’s point of view.

The Box Model

Layout is all about boxes. A box is a rectangular section of a web page. It has a width, a height, and a position on the page. This rectangle is called the content area because it’s where the box’s content is drawn. The content may be text, image, video, or other boxes.

A box may also have padding, borders, and margins surrounding its content area. The CSS spec has a diagram showing how all these layers fit together.

Robinson stores a box’s content area and surrounding areas in the following structure. [Rust note: f32 is a 32-bit floating point type.]

// CSS box model. All sizes are in px.
struct Dimensions {
    // Top left corner of the content area, relative to the document origin:
    x: f32,
    y: f32,

    // Content area size:
    width: f32,
    height: f32,

    // Surrounding edges:
    padding: EdgeSizes,
    border: EdgeSizes,
    margin: EdgeSizes,
}

struct EdgeSizes {
    left: f32,
    right: f32,
    top: f32,
    bottom: f32,
}

Block and Inline Layout

Note: This section contains diagrams that won't make sense if you are reading them without the associated visual styles. If you are reading this in a feed reader, try opening the original page in a regular browser tab. I also included text descriptions for those of you using screen readers or other assistive technologies.

The CSS display property determines which type of box an element generates. CSS defines several box types, each with its own layout rules. I’m only going to talk about two of them: block and inline.

I’ll use this bit of pseudo-HTML to illustrate the difference:

Block boxes are placed vertically within their container, from top to bottom.

a, b, c, d { display: block; }

Description: The diagram below shows four rectangles in a vertical stack.

Inline boxes are placed horizontally within their container, from left to right. If they reach the right edge of the container, they will wrap around and continue on a new line below.

a, b, c, d { display: inline; }

Description: The diagram below shows boxes `a`, `b`, and `c` in a horizontal line from left to right, and box `d` in the next line.

Each box must contain only block children, or only inline children. When an DOM element contains a mix of block and inline children, the layout engine inserts anonymous boxes to separate the two types. (These boxes are “anonymous” because they aren’t associated with nodes in the DOM tree.)

In this example, the inline boxes b and c are surrounded by an anonymous block box, shown in pink:

a    { display: block; }
b, c { display: inline; }
d    { display: block; }

Description: The diagram below shows three boxes in a vertical stack. The first is labeled `a`; the second contains two boxes in a horizonal row labeled `b` and `c`; the third box in the stack is labeled `d`.

Note that content grows vertically by default. That is, adding children to a container generally makes it taller, not wider. Another way to say this is that, by default, the width of a block or line depends on its container’s width, while the height of a container depends on its children’s heights.

This gets more complicated if you override the default values for properties like width and height, and way more complicated if you want to support features like vertical writing.

The Layout Tree

The layout tree is a collection of boxes. A box has dimensions, and it may contain child boxes.

struct LayoutBox<'a> {
    dimensions: Dimensions,
    box_type: BoxType<'a>,
    children: Vec<LayoutBox<'a>>,
}

A box can be a block node, an inline node, or an anonymous block box. (This will need to change when I implement text layout, because line wrapping can cause a single inline node to split into multiple boxes. But it will do for now.)

enum BoxType<'a> {
    BlockNode(&'a StyledNode<'a>),
    InlineNode(&'a StyledNode<'a>),
    AnonymousBlock,
}

To build the layout tree, we need to look at the display property for each DOM node. I added some code to the style module to get the display value for a node. If there’s no specified value it returns the initial value, 'inline'.

enum Display {
    Inline,
    Block,
    DisplayNone,
}

impl StyledNode {
    /// Return the specified value of a property if it exists, otherwise `None`.
    fn value(&self, name: &str) -> Option<Value> {
        self.specified_values.find_equiv(&name).map(|v| v.clone())
    }

    /// The value of the `display` property (defaults to inline).
    fn display(&self) -> Display {
        match self.value("display") {
            Some(Keyword(s)) => match s.as_slice() {
                "block" => Block,
                "none" => DisplayNone,
                _ => Inline
            },
            _ => Inline
        }
    }
}

Now we can walk through the style tree, build a LayoutBox for each node, and then insert boxes for the node’s children. If a node’s display property is set to 'none' then it is not included in the layout tree.

/// Build the tree of LayoutBoxes, but don't perform any layout calculations yet.
fn build_layout_tree<'a>(style_node: &'a StyledNode<'a>) -> LayoutBox<'a> {
    // Create the root box.
    let mut root = LayoutBox::new(match style_node.display() {
        Block => BlockNode(style_node),
        Inline => InlineNode(style_node),
        DisplayNone => fail!("Root node has display: none.")
    });

    // Create the descendant boxes.
    for child in style_node.children.iter() {
        match child.display() {
            Block => root.children.push(build_layout_tree(child)),
            Inline => root.get_inline_container().children.push(build_layout_tree(child)),
            DisplayNone => {} // Skip nodes with `display: none;`
        }
    }
    return root;
}

impl LayoutBox {
    /// Constructor function
    fn new(box_type: BoxType) -> LayoutBox {
        LayoutBox {
            box_type: box_type,
            dimensions: Default::default(), // initially set all fields to 0.0
            children: Vec::new(),
        }
    }
}

If a block node contains an inline child, create an anonymous block box to contain it. If there are several inline children in a row, put them all in the same anonymous container.

impl LayoutBox {
    /// Where a new inline child should go.
    fn get_inline_container(&mut self) -> &mut LayoutBox {
        match self.box_type {
            InlineNode(_) | AnonymousBlock => self,
            BlockNode(_) => {
                // If we've just generated an anonymous block box, keep using it.
                // Otherwise, create a new one.
                match self.children.last() {
                    Some(&LayoutBox { box_type: AnonymousBlock,..}) => {}
                    _ => self.children.push(LayoutBox::new(AnonymousBlock))
                }
                self.children.mut_last().unwrap()
            }
        }
    }
}

This is intentionally simplified in a number of ways from the standard CSS box generation algorithm. For example, it doesn’t handle the case where an inline box contains a block-level child. Also, it generates an unnecessary anonymous box if a block-level node has only inline children.

To Be Continued…

Whew, that took longer than I expected. I think I’ll stop here for now, but don’t worry: Part 6 is coming soon, and will cover block-level layout.

Once block layout is finished, we could jump ahead to the next stage of the pipeline: painting! I think I might do that, because then we can finally see the rendering engine’s output as pretty pictures instead of just numbers.

However, the pictures will just be a bunch of colored rectangles, unless we finish the layout module by implementing inline layout and text layout. If I don’t implement those before moving on to painting, I hope to come back to them afterward.

http://limpet.net/mbrubeck/2014/09/08/toy-layout-engine-5-boxes.html

Snipped from irrelevant context:

 In this case I see nearby code asserting that IsCompiled() is true, so I think I have it right

Assertions do more than point out mistakes in code. They also document that code’s intended behavior, permitting faster iteration and modification to that code by future users. Assertions are often more valuable as documentation, than they are as a means to detect bugs. (Although not always. *eyes fuzzers beadily*)

So don’t just assert the tricky requirements: assert the more-obvious ones, too. You may save the next person changing the code (and the person reviewing it, who could be you!) a lot of time.

http://whereswalden.com/2014/09/08/quote-of-the-day-2/

There is something magical about how anyone anywhere can contribute to Mozilla—people show up and help you with something you’re doing or offer you something completely new and unexpected.

The Code Rush documentary has a great example of this from the time when the Mozilla project first launched. Netscape opened it’s code to the world in the hope that people would contribute, but there was no guarantee that anyone would help.

One of the first signs they had that this was working was when Stuart Parmenter started contributing by rewriting a key part of the code and this accelerated development work by months. (This is about 27 minutes into the documentary.)

It is hard to plan and schedule around magic though. This year we’ve been building up a participation system that will help make contributions more reliable and predictable, so that teams can plan and schedule around leveraging the Mozilla community.

Pathways, tools and education are part of that system. Something else we’re trying is contribution challenges. These will identify unmet needs where scale and asynchronous activities can provide impact in the short-term and where there is strong interest within the volunteer community.

The challenges will also specify the when, where, who and how of the idea, so that we can intentionally design for participation at the beginning and have a prepared way that we’re rallying people to take action.

For next steps, leadership of the Mozilla Reps program is meeting in Berlin from September 12-14 and they’ll be working on this concept as well as on some specific challenge ideas. There will be more to share after that.

If you’re interested in helping with this and want to get involved, take a look at the contribution challenges etherpad for more background and a list of challenge ideas. Then join the community building mailing list and share your thoughts, comments and questions.

http://davidwboswell.wordpress.com/2014/09/08/creating-community-contribution-challenges/

Benjamin Smedberg recently announced that he was handing over XPCOM module ownership duties to me.  XPCOM contains basic data structures used throughout the Mozilla codebase, so changes to its code can have wide-ranging effects.  I’m honored to have been given responsibility for a core piece of the Gecko platform.

One issue that’s come up recently and I’m sure will continue to come up is changing XPCOM data structures to support two new C++11 features, rvalue references and their killer app, move constructors.  If you aren’t familiar with C++11’s new rvalue references feature, I highly recommend C++ Rvalue References Explained.  Move constructors are already being put to good use elsewhere in the codebase, notably mozilla::UniquePtr, which can be used to replace XPCOM’s nsAutoPtr and nsAutoRef (bug 1055035).  And some XPCOM data structures have received the move constructor treatment, notably nsRefPtr (bug 980753) and nsTArray (bug 982212).

A recent discussion and the associated bug, however, decided that the core referenced-counted smart pointer class in XPCOM, nsCOMPtr, shouldn’t support move constructors.  While move constructors could have replaced the already_AddRefed usage associated with nsCOMPtr, such as:

already_AddRefed
NS_DoSomething(...)
{
  nsCOMPtr interface = ...;
  // do some initialization stuff
  return interface.forget();
}

with the slightly shorter:

nsCOMPtr
NS_DoSomething(...)
{
  nsCOMPtr interface = ...;
  // do some initialization stuff
  return interface;
}

There were two primary arguments against move constructor support.  The first argument was that the explicitness of having to call .forget() on an nsCOMPtr (along with the explicitness of the already_AddRefed type), rather than returning it, is valuable for the code author, the patch reviewer, and subsequent readers of the code.  When dealing with ownership issues in C++, it pays to be more explicit, rather than less.  The second argument was that due to the implicit conversion of nsCOMPtr to a bare T* pointer (a common pattern in smart pointer classes), returning nsCOMPtr from functions makes it potentially easy to write buggy code:

// What really happens in the below piece of code is something like:
//
// nsIMyInterface* p;
// {
//   nsCOMPtr tmp(NS_DoSomething(...));
//   p = tmp.get();
// }
//
// which is bad if NS_DoSomething is returning the only ref to the object.
// p now points to deleted memory, which is a security risk.
nsIMyInterface* p = NS_DoSomething(...);

(I should note that we can return nsCOMPtr from functions today, and in most cases, thanks to compiler optimizations, it will be as efficient as returning already_AddRefed.  But Gecko culture is such that a function returning nsCOMPtr would be quite unusual, and therefore unlikely to pass code review.)

The changes to add move constructors to nsRefPtr and nsTArray?  They were reviewed by me.  And the nixing of move constructors for nsCOMPtr?  That was also done by me (with a lot of feedback from other people).

I accept the charge of inconsistency.  However, I offer the following defense.  In the case of nsTArray, there are no ownership issues like there are with nsCOMPtr: you either own the array, or you don’t, so many of the issues raised about nsCOMPtr don’t apply in that case.

For the case of nsRefPtr, it is true that I didn’t seek out as much input from other people before approving the patch.  But the nsRefPtr patch was also done without the explicit goal of removing already_AddRefed from the code base, which made it both smaller in scope and more palatable.  Also, my hunch is that nsRefPtr is used somewhat less than nsCOMPtr (although this may be changing somewhat given other improvements in the codebase, like WebIDL), and so it provides an interesting testbed for whether move constructors and/or less explicit transfers of ownership are as much of a problem as argued above.

https://blog.mozilla.org/nfroyd/2014/09/08/xpcom-and-move-constructors/