I Use This!
Very High Activity

News

Analyzed 11 days ago. based on code collected 11 days ago.
Posted 1 day ago by David Humphrey
This week I'm talking with my open source students about bugs. Above all, I want them to learn how The Bug is the unit of work of open source. Learning to orient your software practice around the idea that we incrementally improve an existing piece ... [More] of code (or a new one) by filing, discussing, fixing, and landing bugs is an important step. Doing so makes a number of things possible: it socializes us to the fact that software is inherently buggy: all code has bugs, whether we are aware of them yet or not. Ideally this leads to an increased level of humility it allows us to ship something now that's good enough, and improve it as we go forward. This is in contrast to the idea that we'll wait until things are done or "correct." it provides an interface between the users and creators of software, where we can interact outside purely economic relationships (e.g., buying/selling). connected with the above, it enables a culture of participation. Understanding how this culture works provides opportunities to become involved. One of the ways that new people can participate in open source projects is through Triaging existing bugs: testing if a bug (still) exists or not, connecting the right people to it, providing more context, etc. As I teach these ideas this week, I thought I'd work on triaging a bug in a project I haven't touched before. When you're first starting out in open source, the process can be very intimidating and mysterious. Often I find my students look at what goes on in these projects as something they do vs. something I could do. It almost never feels like you have enough knowledge or skill to jump in and join the current developers, who all seem to know so much. The reality is much more mundane. The magic you see other developers doing turns out to be indistinguishable from trial and error, copy/pasting, asking questions, and failing more than you succeed. It's easy to confuse the end result of what someone else does with the process you'd need to undergo if you wanted to do the same. Let me prove it too you: let's go triage a bug. TensorFlow and TensorBoard One of the projects that's trending right now on GitHub is Google's open source AI and Machine Learning framework, TensorFlow. I've been using TensorFlow in a personal project this year to do real-time image classification from video feeds, and it's been amazing to work with and learn. There's a great overview video of the kinds of things Google and others are doing with TensorFlow to automate all kinds of things on the tensorflow.org web site, along with API docs, tutorials, etc. TensorFlow is just under 1 million lines of C++ and Python, and has over 1,100 contributors. I've found the quality of the docs and tools to be first class, especially for someone new to AI/ML like myself. One of those high quality tools is TensorBoard. TensorBoard is a Python-based web app that reads log data generated by TensorFlow as it trains a network. With TensorBoard you can visualize your network, understand what's happening with learning and error rates, and gain lots of insight into what's actually going on with your training runs. There's an excellent video from this year's TensorFlow Dev Summit (more videos at that link) showing a lot of the cool things that are possible. A Bug in TensorBoard When I started using TensorFlow and TensorBoard this spring, I immediately hit a bug. My default browser is Firefox, and here's what I saw when I tried to view TensorBoard locally: Notice all the errors in the console related to Polymer and document.registerElement not being a function. It looks like an issue with missing support for Custom Elements. In Chrome, everything worked fine, so I used that while I was iterating on my neural network training. Now, since I have some time, I thought I'd go back and see if this was fixable. The value of having the TensorBoard UI be web based is that you should be able to use it in all sorts of contexts, and in all sorts of browsers. Finding/Filing the Bug My first step was to see if this bug was known. If someone has already filed it, then I won't need to; it may even be that someone is already fixing it, or that it's fixed in an updated version. I begin by looking at the TensorBoard repo's list of Issues. As I said above, one of the amazing things about true open source projects is that more than just the code is open: so too is the process by which the code evolves in the form of bugs being filed/fixed. Sometimes we can obtain a copy of the source for a piece of software, but we can't participate in its development and maintenance. It's great that Google has put both the code and entire project on GitHub. At the time of writing, there are only 120 open issues, so one strategy would be to just look through them all for my issue. This often won't be possible, though, and a better approach is to search the repo for some unique string. In this case, I have a bunch of error messages that I can use for my search. I search for document.registerElement and find 1 issue, which is a lovely outcome: Issue #236: tensor board does not load in safari is basically what I'm looking for, and discusses the same sorts of errors I saw in Firefox, but in the context of Safari. Lesson: often a bug similar to your own is already filed, but may be hiding behind details different from the one you want to file. In this case, you might unknowingly file a duplicate (dupe), or add your information to an existing bug. Don't be afraid to file the bug: it's better to have it filed in duplicate than for it to go unreported. Forking and Cloning the repo Now that I've found Issue #236, I have a few options. First, I might decide that having this bug filed is enough: someone on the team can fix it when they have time. Another possibility is that I might have found that someone was already working on a fix, and a Pull Request was open for this Issue, with code to address the problem. A third option is for you to fix the bug yourself, and this is the route I want to go now. My first step is to Fork the TensorBoard repo into my own GitHub account. I need a version of the code that I can modify vs. just read. Once that completes, I'll have an exact copy of the TensorBoard repo that I control, and which I can modify. This copy lives on GitHub. To work with it on my laptop, I'll need to Clone it to my local computer as well, so that I can make and test changes: Setting up TensorBoard locally I have no idea how to run TensorBoard from source vs. as part of my TensorFlow installation. I begin by reading their README.md file. In it I notice a useful discussion within the Usage section, which talks about how to proceed. First I'll need to install Bazel. Lesson: in almost every case where you'll work on a bug in a new project, you'll be asked to install and setup a development environment different from what you already have/know. Take your time with this, and don't give up too easily if things don't go as smoothly as you expect: many fewer people test this setup than do the resulting project it is meant to create. Bazel is a build/test automation tool built and maintained by Google. It's available for many platforms, and there are good instructions for installing it on your particular OS. I'm on macOS, so I opt for the Homebrew installation. This requires Java, which I also install. Now I'm able to try and do the build I follow the instructions in the README, and within a few seconds get an error: $ cd tensorboard $ bazel build tensorboard:tensorboard Extracting Bazel installation... ............. ERROR: /private/var/tmp/_bazel_humphd/d51239168182c03bedef29cd50a9c703/external/local_config_cc/BUILD:49:5: in apple_cc_toolchain rule @local_config_cc//:cc-compiler-darwin_x86_64: Xcode version must be specified to use an Apple CROSSTOOL. ERROR: Analysis of target '//tensorboard:tensorboard' failed; build aborted. INFO: Elapsed time: 8.965s This error is a typical example of the kind of problem one encounters working on a new project. Specifically, it's OS specific, and relates to a first-time setup issue--I don't have XCode setup properly. I spend a few minutes searching for a solution. I look to see if anyone has filed an issue with TensorBoard on GitHub specifically about this build error--maybe someone has had this problem before, and it got solved? I also Google to see if anyone has blogged about it or asked on StackOverflow: you are almost never the only person who has hit a problem. I find some help on StackOverflow, which suggests that I don't have XCode properly configured (I know it's installed). It suggests some commands I can try to fully configure things, none of which solve my issue. It looks like it wants the full version of XCode vs. just the commandline tools. The full XCode is massive to download, and I don't really want to wait, so I do a bit more digging to see if there is any other workaround. This may turn out to be a mistake, and it might be better to just do the obvious thing instead of trying to find a workaround. However, I'm willing to spend an additional 20 minutes of research to save hours of downloading. Some more searching reveals an interesting issue on the Bazel GitHub repo. Reading through the comments on this issues, it's clear that lots of other people have hit this--it's not just me. Eventually I read this comment, with 6 thumbs-up reactions (i.e., some agreement that it works): just for future people. sudo xcode-select -s /Applications/Xcode.app/Contents/Developer could do the the trick if you install Xcode and bazel still failing. This allows Bazel to find my compiler and the build to proceed further...before stopping again with a new error: clang: error: unknown argument: '-fno-canonical-system-headers'. This still sounds like a setup issue on my side vs. something in the TensorBoard code, so I keep reading. This discussion on the Bazel Google Group seems useful: it sounds like I need to clean my build and regenerate things, now that my XCode toolchain is properly setup. I do that, and my build completes without issue. Lesson: getting this code to build locally required me to consult GitHub, StackOverflow, and Google Groups. In other words, I needed the community to guide me via asking and answering questions online. Don't be afraid to ask questions in public spaces, since doing so leaves traces for those who will follow in your footsteps. Running TensorBoard Now that I've built the source, I'm ready to try running it. TensorBoard is meant to be used in conjunction with Tensorflow. In this case, however, I'm interested in using it on its own, purely for the purpose of reproducing my bug, and testing a fix. I don't actually care about having Tensorflow and real training data to visualize. I notice that the DEVELOPMENT.md file seems to indicate that it's possible to fake some training data and use that in the absence of a real TensorFlow project. I try what it suggests, which fails: ... line 40, in create_summary_metadata metadata = tf.SummaryMetadata( AttributeError: 'module' object has no attribute 'SummaryMetadata' ERROR: Non-zero return code '1' from command: Process exited with status 1. From having programmed with TensorFlow before, I assume here that tf (i.e. the TensorFlow Python module) is missing an expected attribute, namely, SummaryMetadata. I've never heard of it, but Google helps me locate the necessary API docs. This leads me to conclude that my installed version of TensorFlow (I installed it 4 months earlier) might not have this new API, and the code in TensorBoard now expects it to exist. The API docs I'm consulting are for version 1.3 of the TensorFlow API. What do I have installed? $ pip search tensorflow ... INSTALLED: 1.2.1 LATEST: 1.3.0 Maybe upgrading from 1.2.1 to 1.3.0 will solve this? I update my laptop to TensorFlow 1.3.0 and am now able to generate the fake data for TensorBoard. Lesson: running portions of a larger project in isolation often means dealing with version issues and manually installing dependencies. Also, sometimes dependencies are assumed, as was TensorFlow 1.3 in this case. Likely the TensorBoard developers all have TensorFlow installed and/or are developing it at the same time. In cases like this a README may not mention all the implied dependencies. Using this newly faked data, I try running my version of TensorBoard...which again fails with a new error: ... from tensorflow.python.debug.lib import grpc_debug_server ImportError: cannot import name grpc_debug_server ERROR: Non-zero return code '1' from command: Process exited with status 1. After some more searching, I find a 10-day old open bug in TensorBoard itself. This particular bug seems to be another version skew issue between dependencies, TensorFlow, and TensorBoard. The module in question, grpc_debug_server, seems to come from TensorFlow. Looking at the history of this file, the code is pretty new, making me wonder if it is once again that I'm running something with an older API. A comment in this issue gives a clue as to a possible fix: FYI, I ran into the same problem, and I did pip install grpc which seemed to fix the problem. I give this a try, but TensorBoard still won't run. Further on in this issue I read another comment indicating I need the "nightly version of TensorFlow." I've never worked with the nightly version of TensorFlow before (didn't know such a thing existed), and I have no idea how to install that (the comment assumes one knows how to do this). A bit more searching reveals the answer, and I install the nightly version: $ pip install tf-nightly Once again I try running my TensorBoard, and this time, it finally works. Lesson: start by assuming that an error you're seeing has been encountered before, and go looking for an existing issue. If you don't find anything, maybe you are indeed the first person to hit it, in which case you should file a new issue yourself so you can start a discussion and work toward a fix. Everyone hits these issues. Everyone needs help. Reproducing the Bug With all of the setup now behind us, it's time to get started on our actual goal. My first step in tackling this bug is to make sure I can reproduce it, that is, make sure I can get TensorBoard to fail in Safari and Firefox. I also want to confirm that things work in Chrome, which would give me some assurance that I've got a working source build. Here's my local TensorBoard running in Chrome: Next I try Safari: And...it works? I try Firefox too: And this works too. At this point I have two competing emotions: I'm pleased to see that the bug is fixed. I'm frustrated that I've done all this work to accomplish nothing--I was hoping I could fix it. The Value of Triaging Bugs It's kind of ironic that I'm upset about this bug being fixed: that's the entire point of my work, right? I would have enjoyed getting to try and fix this myself, to learn more about the code, to get involved in the project. Now I feel like I have nothing to contribute. Here I need to challenge my own feelings (and yours too if you're agreeing with me). Do I really have nothing to offer after all this work? Was it truly wasted effort? No, this work has value, and I have a great opportunity to contribute something back to a project that I love. I've been able to discover that a previous bug has been unknowingly fixed, and can now be closed. I've done the difficult work of Confirming and Triaging a bug, and helping the project to close it. I leave a detailed comment with my findings. This then causes the bug to get closed by a project member with the power to do so. So the result of my half-day of fighting with TensorBoard is that a bug got closed. That's a great outcome, and someone needed to do this work in order for this to happen. My willingness to put some effort into it was key. It's also paved the way for me to do follow-up work, if I choose: my computer now has a working build/dev environment for this project. Maybe I will work on another bug in the future. There's more to open source than fixing bugs: people need to file them, comment on them, test them, review fixes, manage them through their lifetime, close them, etc. We can get involved in any/all of these steps, and it's important to realize that your ability to get involved is not limited to your knowledge of how the code works. [Less]
Posted 1 day ago by Camelia Badau
Hello Mozillians! As you may already know, last Friday – September 15th – we held a new Testday event, for Developer Edition 56 Beta 12. Thank you all for helping us make Mozilla a better place – Athira Appu. From India team: Baranitharan & ... [More] BaraniCool, Abirami& AbiramiSD, Vinothini.K, Surentharan, vishnupriya.v, krishnaveni.B, Nutan sonawane, Shubhangi Patil, Ankita Lahoti, Sonali Dhurjad, Yadnyesh Mulay, Ankitkumar Singh. From Bangladesh team: Nazir Ahmed Sabbir, Tanvir Rahman, Maruf Rahman, Saddam Hossain, Iftekher Alam, Pronob Kumar Roy, Md. Raihan Ali, Sontus Chandra Anik, Saheda Reza Antora, Kazi Nuzhat Tasnem, Md. Rahimul Islam, Rahim Iqbal, Md. Almas Hossain, Ali sarif, Md.Majedul islam, JMJ Saquib, Sajedul Islam, Anika Alam, Tanvir Mazharul, Azmina Akter Papeya, sayma alam mow.  Results: – several test cases executed for the Preferences Search, CSS Grid Inspector Layout View and Form Autofill features. – 6 bugs verified: 1219725 , 1373935, 1391014 , 1382341, 1383720 , 1377182 – 1 new bug filed: 1400203 Thanks for another successful testday We hope to see you all in our next events, all the details will be posted on QMO! [Less]
Posted 1 day ago by nore...@blogger.com (Rabimba Karanjai)
Linux Foundation held a combination of three events in China as part of their foray into Asia early this year. It was a big move for them since this was supposed to be the first time Linux Foundation would hold an event in Asia. I was invited to ... [More] present a talk on Hardening IoT endpoints. The event was held in Beijing, and since I have never been to Beijing before I was pretty excited for the talk. However, it turned out the journey is pretty long and expensive. Much more than a student like me can hope to bear. Normally I represent Mozilla in such situations, but the topic of the talk was too much into security and not aligned much with the goals of Mozilla at that moment. Fortunately, Linux Foundation gave me a Scholarship to come and speak at LinuxCon China which enabled me to attend LinuxCon and the awesome team at Mozilla TechSpeakers including Michael Ellis and Havi helped me get ready for the talk. The event was held at China National Convention Center. It's a beautiful and enormous convention center just middle of Beijing. One of the big problems I soon realized after reaching China is, most of the services in my mobile was not working. The great wall (the firewall not the actual one) was preventing most of the Google services I had, unfortunately, that included two apps I was heavily relying on. Google Maps and Google Translate. There, of course, is a local alternative to Google Maps which is Baidu Maps, but since the interface itself also was in Chinese, it wasn't of much help to me. Fortunately, my VPN setup came into my rescue and that has been my source of relief for the next two days in China. Pro Tip: If you have to goto china and you rely on some form of service which might be blocked in China. It's better to use a good VPN. One you know will work there or roll your own. I had rolled my own since my commercial vpn also was blocked there. The day started with Linus Trovalds having an open discussion regarding which way Linux is moving. And with very interesting aspects and views.One of the recurring theme in the discussion, which kept coming up was regarding how the core linux maintainer circle worked. And why it was being relied on only one those very few people. The reply was most stimulating.The very interesting quote from him was "10 top maintainers is very strong team in an open source project" @Linus__Torvalds #linuxcon @linuxfoundation pic.twitter.com/B6TQihUTce — Rabimba Karanjai (@rabimba) June 20, 2017 Among the other talks I really liked: Amir's talk on Unikernal James's talk on Hardening TPM from IBM Research Scheduling and Resource Management in Kubernates UEFI Http/https boot The other talks were interesting as well. I would have really liked to attend three more talks, namely by Greg on serverless computing on edge, by Swati on Kubernates and by Kai Zhang on container-based virtualization, but that one clashed with my own talk.My talk was on the second day and on a relatively good time, which was especially important for me as the conference wifi was the only one where I could work on my slides.Lesson Learned: Don't rely on Google Slides in ChinaFortunately courtesy to my vpn I was able to work on it and have a backup local copy ready for the talk. That room was pretty big, didn't see this coming What I did not anticipate earlier was how eager people were for the talk. In a nutshell this was how the room was looking when I took the podium.My first reaction was: Wow that's a lot of people! Guess they are really interested in the talk!And then: Shit! I hope my talk is as interesting as all of the super industry relevant talks going on around me in all other rooms.Fortunately, the talk went pretty well. I always judge my talk based on how many queries, questions I get after the talk and also how many reactions in twitter. Judging on the number of queries afterwards I guessed atleast it wasn't that bad. I was though super disappointed on the complete radio silence in twitter regarding my talk. Only to realize later that twitter is also blocked in China.To Do: Next time come up with better ways to track engagement.My only complain here was, normally every Linux Foundation conference records your talk. LinuxCon didn't. Though they did upload all our slides, so if you want to go over a textual version of what I presented, have a sneak peak here. I will be all ears to listen to your feedback SecurityPI - Hardening your IoT endpoints in Home. from LinuxCon ContainerCon CloudOpen China This would have normally finished my recount of the event, but this time it didn't I finally went to a BoF session on Fedora and CentOS, and ended up having a 2 hour long discussion on the various issues Mozilla and Fedora communities face and pain points with Brian Exelbierd. We temporarily suspended the discussion with no clear path to a solution but with a notion to touch base with each other again on it.Conclusion: LinuxCon was a perfect example of how to handle and manage a huge footfall with a multilingual audience and still make the conference good. The quality of the talks was astounding as well as speakers. I really loved my experience there. Made some great friends (I am looking at you Greg and Swati :D), had some awesome conversation.And did I mention the speakers at the day caught up and decided we needed a memoir for us? Which happens to be us discussing everything related to Linux to Mozilla to security in Forbidden City That in a nutshell were the speakers Like I said, one hell of a conference. PS: If you want to talk to me about anything related to the talk, don't hesitate to get in touch using either my email or twitter. [Less]
Posted 4 days ago by Justin O'Kelly
This week I had the opportunity to share Mozilla’s vision for an Internet that is open and accessible to all with the audience at MWC Americas. I took this opportunity because we are at a pivotal point in the debate between the FCC, companies, and ... [More] users over the FCC’s proposal to roll back protections for net neutrality. Net neutrality is a key part of ensuring freedom of choice to access content and services for consumers. Earlier this week Mozilla’s Heather West wrote a letter to FCC Chairman Ajit Pai highlighting how net neutrality has fueled innovation in Silicon Valley and can do so still across the United States. The FCC claims these protections hamper investment and are bad for business. And they may vote to end them as early as October. Chairman Pai calls his rule rollback “restoring internet freedom” but that’s really the freedom of the 1% to make decisions that limit the rest of the population. At Mozilla we believe the current rules provide vital protections to ensure that ISPs don’t act as gatekeepers for online content and services. Millions of people commented on the FCC docket, including those who commented through Mozilla’s portal that removing these core protections will hurt consumers and small businesses alike. Mozilla is also very much focused on the issues preventing people coming online beyond the United States. Before addressing the situation in the U.S., journalist Rob Pegoraro asked me what we discovered in the research we recently funded in seven other countries into the impact of zero rating on Internet use: (Video courtesy: GSMA) If you happen to be in San Francisco on Monday 18th September please consider joining Mozilla and the Internet Archive for a special night: The Battle to Save Net Neutrality. Tickets are available here. You’ll be able to watch a discussion featuring former FCC Chairman Tom Wheeler; Representative Ro Khanna; Mozilla Chief Legal and Business Officer Denelle Dixon; Amy Aniobi, Supervising Producer, Insecure (HBO); Luisa Leschin, Co-Executive Producer/Head Writer, Just Add Magic (Amazon); Malkia Cyril, Executive Director of the Center for Media Justice; and Dane Jasper, CEO and Co-Founder of Sonic. The panel will be moderated by Gigi Sohn, Mozilla Tech Policy Fellow and former Counselor to Chairman Wheeler. It will discuss how net neutrality promotes democratic values, social justice and economic opportunity, what the current threats are, and what the public can do to preserve it. [Less]
Posted 4 days ago by Mitchell Baker
This week I had the opportunity to share Mozilla’s vision for an Internet that is open and accessible to all with the audience at MWC Americas. I took this opportunity because we are at a pivotal point in the debate between the FCC, companies, and ... [More] users over the FCC’s proposal to roll back protections for net neutrality. Net neutrality is a key part of ensuring freedom of choice to access content and services for consumers. Earlier this week Mozilla’s Heather West wrote a letter to FCC Chairman Ajit Pai highlighting how net neutrality has fueled innovation in Silicon Valley and can do so still across the United States. The FCC claims these protections hamper investment and are bad for business. And they may vote to end them as early as October. Chairman Pai calls his rule rollback “restoring internet freedom” but that’s really the freedom of the 1% to make decisions that limit the rest of the population. At Mozilla we believe the current rules provide vital protections to ensure that ISPs don’t act as gatekeepers for online content and services. Millions of people commented on the FCC docket, including those who commented through Mozilla’s portal that removing these core protections will hurt consumers and small businesses alike. Mozilla is also very much focused on the issues preventing people coming online beyond the United States. Before addressing the situation in the U.S., journalist Rob Pegoraro asked me what we discovered in the research we recently funded in seven other countries into the impact of zero rating on Internet use: (Video courtesy: GSMA) If you happen to be in San Francisco on Monday 18th September please consider joining Mozilla and the Internet Archive for a special night: The Battle to Save Net Neutrality. Tickets are available here. You’ll be able to watch a discussion featuring former FCC Chairman Tom Wheeler; Representative Ro Khanna; Mozilla Chief Legal and Business Officer Denelle Dixon; Amy Aniobi, Supervising Producer, Insecure (HBO); Luisa Leschin, Co-Executive Producer/Head Writer, Just Add Magic (Amazon); Malkia Cyril, Executive Director of the Center for Media Justice; and Dane Jasper, CEO and Co-Founder of Sonic. The panel will be moderated by Gigi Sohn, Mozilla Tech Policy Fellow and former Counselor to Chairman Wheeler. It will discuss how net neutrality promotes democratic values, social justice and economic opportunity, what the current threats are, and what the public can do to preserve it. The post Busting the myth that net neutrality hampers investment appeared first on The Mozilla Blog. [Less]
Posted 4 days ago by Smokey
But one of the ways that I believe people express their appreciation to the rest of humanity is to make something wonderful and put it out there. —Steve Jobs (date unknown, as played at the opening of the Steve Jobs Theater, September 12, 2017) ... [More] When I read this1 the other day, my first thought was of Camino. We were often asked by outsiders why we worked on Camino, and why we persisted in building Camino for so long after Safari, Firefox, and Chrome were launched. In the minds of many of these people, our time and talents would have been better-spent working on anything other than Camino. While we all likely had different reasons, there were many areas of commonality; primarily, and most importantly, we loved or enjoyed working on Camino. Among other reasons, I also liked that I could see that my efforts made a difference; I wasn’t some cog in a giant, faceless machine, but a valued member of a strong, small team and a part of a larger community of our users who relied on Camino for their daily browsing and livelihoods. It was a way to “give back” to the world (and the open-source community) for things that were useful and positive in my life, to show appreciation. We were making something wonderful, and we put it out there for the world to use.          1 Part of a heretofore publicly-unheard address from Steve Jobs that was played at the opening of the Steve Jobs Theater and the Apple fall 2017 product launches. ↩︎ [Less]
Posted 4 days ago by Air Mozilla
Once a month web developers across the Mozilla community get together (in person and virtually) to share what cool stuff we've been working on in...
Posted 4 days ago by David Humphrey
Let me start by saying that I'm a huge fan of open source projects putting a Good-First-Bug type label on issues. From my own experience over the past decade trying to get students engaged in open source projects, it's often a great way to quickly ... [More] find entry points for new people. Right now I've got 40 students learning open source with me at Seneca, and because I want to get them all working on bugs ASAP, you better believe that I'm paying close attention to good-first-bug labels! Maintainers There are a few ways that we tend to interact with good-first-bugs. First, we have project maintainers who add the label when they think they see something that might be a good fit for someone new. I've been this person, and I know that it takes some discipline to not fix every bug. To be honest, it's faster and easier to just fix small things yourself. It's also going to mean you end up having to fix everything yourself--you won't grow new contributors this way. What you need to do instead is to write large amounts of prose of the type "Here's what you need to do if you're interested in fixing this". You need sample code, links to relevant files, screenshots, etc. so that someone who lands in this bug can readily assess whether their current skill level (or aspirational skill level), and the bug's requirements, meet. Sometimes maintainers opt not to do this, and instead say, "I'd be willing to mentor this." The problem with this approach, in my experience, is that it becomes a kind of debt with which you saddle your future self. Are you sure you'll want to mentor this bug in 2 years, when it's no longer on your roadmap? You'd be better to "mentor" the bug upfront, and just spell out what has to happen in great detail: "Do this, this, and this." If you can't do that, the reality is it's not a good-first-bug. New Contributors The second way we encounter good-first-bugs is as someone looking for an opportunity to contribute. I make a habit of finding/fixing these in various projects so that I can use real examples to show my students the steps. I also tag along with my students as they attempt them, and I've seen it all. It's interesting what you encounter on this side of things. Sometimes it goes exactly as you'd hope: you make the fix and the patch is accepted. However, more often then not you run into snags. First, before you even get going on a fix, finding a bug that isn't already being worked on can be hard. A lot of people are looking for opportunities to get started, and when you put up a sign saying "Start Here," people will! Read through the comments on many good-first-bugs and you'll find an unending parade of "I'd like to work on this bug!" and "Can you assign this to me?" followed by "Are you still working on this?" and "I'm new, can you help me get started?". That stream of comments often repeats forever, leaving the project maintainers frustrated, the contributors lost, and the bug untouched. Expiry Dates Once people do get started on a bug, another common problem I see is that the scope of the bug has shifted such that the problem/fix described no longer makes sense. You see a lot of responses like this: "Thanks for this fix, but we've totally refactored this code, and it's not necessary any more. Closing!" This doesn't feel great, or make you want to put more effort into finding something else to do. The problem here wasn't that the bug was wrong...when filed. The bug has become obsolete over time. Good-first-bugs really need an expiry date. If a project isn't triaging its good-first-bugs on a somewhat regular basis, it's basically going to end up in this state eventually, with some or all of them being useless, and therefore bad-first-bugs. You're better off closing bugs like this and having no good-first-bugs listed, than to have 50 ancient bugs that no one on the project cares about, wants to review, or has time to discuss. Good First Experience This week I've been thinking a lot about ways to address some of the problems above. In their lab this week, I asked my students to build Firefox, and also to make some changes to the code. I had a few goals with this: Build a large open source project to learn about setting up dev environments, obtaining source code, build systems, etc. Gain some experience making a change and rebuilding Firefox, to prove to themselves that they could do it and to remove some of the mystery around how one does this. Learn how to start navigating around in large code, see how things are built (e.g., Firefox uses JS and CSS for its front-end). Have some fun doing something exciting and a bit scary I've done this many times in the past, and often I've gone looking for a simple good-first-bug to facilitate these goals. This time I wanted to try something different. Instead of a good-first-bug, I wanted what I'll call a "Good First Experience." A Good First Experience tries to do the following: It's reproducible by everyone. Where a good-first-bug is destroyed in being fixed, a good-first-experience doesn't lose its potential after someone completes it. It's not tied to the current state of the project, and therefore doesn't become obsolete (as quickly). Where a good-first-bug is always tied to the project's goals, coding practices, and roadmap, a good-first-experience is independent of the current state of the project. It's meant to be fun, exploratory, and safe. Where a good-first-bug is about accomplishing a task, and is therefore defined and limited by that task, a good-first-experience can be the opposite: an unnecessary change producing an outcome whose value is measured by the participate vs the project. Toward a Good First Experience with Firefox I reached out to a half-dozen Mozilla colleagues for ideas on what we could try (thanks to all who replied). I ended-up going with some excellent suggestions from Blake Winton (@bwinton). Blake has a history of being whimsical in his approach to his work at Mozilla, and I think he really understood what I was after. Based on his suggestions, I gave the students some options to try: In browser/base/content/browser.js change the function OpenBrowserWindow to automatically open cat GIFs. You can alter the code like so: function OpenBrowserWindow(options) { return window.open("http://www.chilloutandwatchsomecatgifs.com"); } Look at the CSS in browser/base/content/browser.css and try changing some of the colours. Modify the way tabs appear by playing with CSS in browser/themes/shared/tabs.inc.css, for example: you could alter things like min-height. You could try adding a background: url(http://i.imgur.com/UkT7jcm.gif); to the #TabsToolbar in browser/themes/windows/browser.css to add something new Modify the labels for menu items like "New Window" in browser/locales/en-US/chrome/browser/browser.dtd to something else. None of these changes are necessary, prudent, or solving a problem. Instead, they are fun, exploratory, and simple. Already students are having some success, which is great to see. Nature via National Park vs. Wilderness I was reflecting that the real difference between a good-first-experience and a real bug is a lot like experiencing nature by visiting a National Park vs. setting out in the wilderness. There isn't a right or wrong way to do this, and both have obvious advantages and disadvantages. However, what National Parks do well is to make the experience of nature accessible to everyone: manicured paths, maps with established trails to follow, amenities so you can bring your family, information. It's obviously not the same as cutting a trail into a forest, portaging your canoe between lakes, or hiking on the side of a mountain. But it means that more people can try the experience of doing the real thing in relative safety, and without a massive commitment of time or effort. It's also a mostly self-guided experience vs. something you need a guide (maintainer) to accomplish. In the end, this experience might be enough for many people, and will help bring awareness and an enriching experience. For others, it will be the beginning of bolder outings into the unknown. I don't think my current attempt represents a definitive good-first-experience in Mozilla, but it's got me thinking more about what one might look like, and I wanted to get you thinking about them too. I know I'm not alone in wanting to bring students into projects like Mozilla and Firefox, and needing a repeatable entry point. [Less]
Posted 5 days ago by Jorge Villalobos
Here’s your monthly add-ons update. The Review Queues In the past month, our team reviewed 2,490 listed add-on submissions: 2,074 in fewer than 5 days (83%). 89 between 5 and 10 days (4%). 327 after more than 10 days (13%). 244 listed add-ons ... [More] are awaiting review. If you’re an add-on developer and are looking for contribution opportunities, please consider joining us. Visit our wiki page for more information. Compatibility Update We published the blog post for 56 and the bulk validation has been run. This is the last one of these we’ll do, since compatibility is a much smaller problem with the WebExtensions API. Firefox 57 is now on the Nightly channel and will soon hit Beta, only accepting WebExtension add-ons by default. Here are some changes we’re implementing on AMO to ease the transition to 57. Recognition We would like to thank the following people for their recent contributions to the add-ons world: Amola Singh yfdyh000 bfred-it Tiago Morais Morgado Divya Rani angelsl Tim Nguyen Atique Ahmed Ziad Apoorva Pandey Kevin Jones ljbousfield asamuzaK Rob Wu Tushar Sinai Trishul Goel zombie tmm88 Christophe Villeneuve Hemanth Kumar Veeranki You can read more about their work in our recognition page. The post Add-ons Update – 2017/09 appeared first on Mozilla Add-ons Blog. [Less]
Posted 5 days ago by ehsan
I hope you’re not tired of reading these newsletters so far.  If not, I applaud your patience with me in the past few months.  But next week, as Firefox 57 will merge to the Beta channel, I’m planning to write the last one of this series. Nightly has ... [More] been pretty solid on performance.  It is prudent at this point to focus our attention more on other aspects of quality for the 57 release, to make sure that things like the crash rate and regressions are under control.  The triage process that we set up in March to enable everyone to take part in finding and nominating performance problems which they think should be fixed in Firefox 57 was started with the goal of creating a large pool of prioritized bugs that we believed would vastly impact the real world performance of Firefox for the majority of our users.  I think this process worked quite well overall, but it has mostly served its purpose, and participating in the triage takes a lot of time (we sometimes had two meetings per week to be able to deal with the incoming volume of bugs!)  With one week left, it seemed like a good decision to stop the triage meetings now.  We also had a weekly 30-minute standup meeting where people talked about what they had done on Quantum Flow during the past week (and you read about many of those in the newsletters!), and for similar reasons that meeting also will be wound down.  This gives back several person-hours back on their calendars to people who really need it, hurray! The work on the Speedometer benchmark for 57 is more or less wrapped up at this point.  One noteworthy change that happened last week which I should mention here is this jump in the numbers which happened on September 7.  The reason behind it was a change on the benchmark side to switch from reporting the score using arithmetic mean to using geometric mean.  This is a good change in my opinion because it means that the impact of a few of the JS frameworks being tested wouldn’t dominate the overall score.  The unfortunate news is that as a result of this change, Firefox took a bigger hit in numbers than Chrome did, but I’m still very proud of all the great work that happened when optimizing for this benchmark, and I think the right response to this change is for us to optimize more to get the few percentages of head-to-head comparison that we lost back.  Even though most of the planned performance work for Firefox 57 is done, it doesn’t mean that people are done pouring in their great fixes as things are making it to the finish line last-minute!  So now please allow me to take a moment to thank everyone who helped make Firefox faster in the last week, as usual, I hope I’m not forgetting any names here: Marco Bonardo improved the performance of the bookmarks toolbar when it has a large number of bookmarks by only dealing with the few bookmarks that would be visible on the toolbar in the code. Will Wang moved the Windows jump lists updater code to the idle queue.  He also moved the sessionstore data collector code in the content process to the idle queue. André Bargull made IsRegExpObject and RegExpInstanceOptimizable inlined in the JIT code.  He also removed some unnecessary rooting in intrinsic_IsConstructor. Kirk Steuber made it so that we try to call ::RegisterDragDrop during idle time which makes it more likely that a DLL will be preloaded off of the main thread, which should improve start-up performance in some cases. Perry Jiang got rid of the contextmenu sync IPC message Adam Gashlin made it so that we cache OS theme margins on Windows Robert Strong made it so that we avoid main thread IO after first run after an update is applied, and when an update is downloaded. This should help improve performance for our Nightly users in particular, since they get updates very often. Andrew McCreight landed the code that allows all JSM’s to share the same compartment. There are general performance and memory benefits to doing this. This is landing disabled by default, and the bug to enable it is here. Kris Maglione sped up some of the MessageChannel.jsm code involved in the webRequest API, among other things.  He also ensured that the JSM script precompiler compiles scripts into the shared JSM global mentioned above to save the cost of cloning them into the destination global before execution.  Kris also removed the add-on SDK from Firefox.  The code inside the add-on SDK was used by some legacy extensions and various internal browser components and was the source of many performance issues, and removing it was the last measure to make sure that such issues would never rise again in the future. Botond Ballo enabled asynchronous scrolling when the scrollbar thumb is dragged using touch input. Olli Pettay removed a GC trigger every time Gecko finished executing some JavaScript.  This was an old trick devised to satisfy benchmarks but he came up with a better fix for that last week. Jon Coppeard changed JavaScript Map and Set objects and their iterators to be allocated from the nursery to benefit from incremental garbage collection. Mason Chang and Bas Schouten enabled specifying a limit on the blend surface area and the portion of the layer being resolved for D2D draw targets. Andrea Marchesini avoided doing main-thread I/O when reading the contents of files read under some situations for some Web APIs that access files.  One example is a file selected using an input element which is read using a FileReader. Mats Palmgren optimized away a lot of the virtual calls to QueryFrame through do_QueryFrame(). Emilio Cobos Álvarez avoided flushing frames in nsHideViewer when we know a new frame won’t be constructed.  This sped up loading new results on Twitter under some circumstances dramatically. [Less]