Valence roadmap

A few days ago I sent the following note to the Firefox devtools mailing list. The point was to start a discussion about where we want to take Valence (née Firefox Developer Tools Adapter) in 2015. I am reproducing the message below in an effort to broaden the audience, but I would encourage anyone who wants to participate in the discussion to post to the mailing list. However, if that sounds too intimidating (it really shouldn't!), I'm always happy to respond to comments in this blog.


Hey fellow devtoolers!

I know that eggnog and Christmas trees is all that everyone is thinking about right now, but I'd like to take a minute before we all indulge in our holiday festivities, to talk about Valence. And 2015.

2015 will be the year when Valence becomes something more than a promising experiment. It is the year that will (hopefully) see a version 1.0 that has feature-parity with Firefox, for features where the Safari/Chrome debugging protocol aligns well with the Firefox RDP. This is a proposed roadmap of how we'll get there from where we are now.

There are two main themes in this roadmap: do more and do better, and I think we should address them in reverse order. Do-things-better contains what I think we need for cutting a 1.0 release:

Improve existing features (do better)

• Get the bundled ios_webkit_debug_proxy working on Windows & Linux
• Implement support for the network panel
• Handle format specifiers in console.log and friends (%s, %c, etc.)
• Display inferred names for functions
• Evaluate expressions in the selected frame when execution is paused
• Support source-mapped CSS
• Break on DOM events
• Fix some longstring-related bugs that we currently work around by using plain strings
• Fix every XXX and TODO comment in the code
• Implement every todoMethod in the actors

Most of these tasks have a well understood scope, so it is just a "small" matter of time and available resources. However, another angle on the do-better theme is not to just fix known problems, but also to make them stay fixed and provide a reliable experience to the user. These tasks belong in that category and should probably be done in parallel with the above:

Improve reliability (do better for realz)

• Deploy some testing infrastructure (probably based on ted's work)
• Port existing Firefox devtools tests and/or write new ones
• Fix stability bugs in Valence

I believe the above lists should be enough for a v1.0, but there are many more things we could do to provide value to our users. Here are some obvious features we could add for a v2.0:

Expand our feature set (do more)

• Support for the performance panel (profiler and timeline)
• Support for the storage panel
• Support for the canvas debugger
• Support for debugging embedded web views on iOS and Android, which would let us become a sort of unofficial development environment for Cordova/PhoneGap
• Support Firefox Developer Tools in the pipeline (memory profiler, worker debugger)

Not all of these tasks have been scoped or had a feasibility assessment, but there are some indications that we should be able to pull them off with some effort. These features would make the value proposition of Valence and (Firefox Developer Edition by extension) really enticing for many more developers.

But when you have all this, why stop there? The adaptability of Firefox Developer Tools that Valence affords can take us to a whole new level of debugging functionality that developers have always dreamed of:

Full-stack debugging (do way more)

• Support debugging server-side node.js applications, with console, scratchpad, debugger and profiler
• (Adding async stack support in Firefox Developer Tools would let us combine server- and client-side stack traces for debugging ecstasy)
• Research the framework ecosystems of languages that compile to JS and can run on node.js and assess the feasibility of supporting them directly via source maps
• Implement adapters for JDWP (to debug Java) and Xdebug (to debug PHP)

Only some preliminary research has gone into these tasks, so their feasibility and effort required is still TBD. Most of the above are further out from a priority standpoint and some may well be in the pie-in-the-sky domain, but I think we should at least investigate node.js debugging in 2015. It would be an exciting engineering accomplishment and could provide a concrete value proposition for Valence and Firefox Developer Edition.

Prioritized shortlist
Given all of the above, and taking difficulty and usefulness into account, I think a reasonable, prioritized, shortlist of Valence tasks for 2015 would be the following:

1. Get the bundled ios_webkit_debug_proxy working on Windows & Linux
2. Display inferred names for functions
3. Implement support for the network panel
4. Fix stability bugs in Valence
5. Deploy some testing infrastructure
6. Port existing Firefox devtools tests and/or write new ones
7. Support debugging server-side node.js applications
8. Support for debugging embedded web views on iOS and Android
9. Handle format specifiers in console.log and friends (%s, %c, etc.)
10. Evaluate expressions in the selected frame when execution is paused
11. Support source-mapped CSS
12. Break on DOM events

Of course, depending on broader organizational priorities, this list may be too short or not much of a shortlist, for an entire year. Not to mention that planning that far ahead is usually futile and an exercise in frustration. Still, this should hopefully provide a useful base for a discussion about what we want Valence to be and how we want to go about it.

Any and all feedback is welcome (before or while you enjoy your eggnog)!

Cheers,
Panos

My 3 year mozversary

A couple of days ago I started my 4th year at Mozilla and as with all anniversaries, it was a good opportunity to step back and reflect on my accomplishments during this past year and where I'm going next. And since Mozilla practices complete transparency, it also seemed like a good opportunity to sit down and write a blog post, as I never seem to get enough time nowadays to do so. Besides, what's the point of having a blog if not for embarrassing yourself every once in a while?

For a year with 4 different CEOs, the first thought that came to mind regarding my performance was: "a bunch of code, a ton of reviews". I didn't know if that was actually true though, so I set out to collect some evidence. All the code metrics I've come across must always be taken with a grain of salt, so I didn't worry about being completely accurate and I don't intend to gauge my progress on these metrics alone, but at least I wanted some quantification of the kind of impact that I had. Besides refactoring and bug fixing, my most useful feature work in this period includes break on DOM events, closure inspection, the memory actor and improved debugger behavior after a reload (edit: forgot to add the tracing debugger and function re-evaluation in Scratchpad).

The first interesting observation [1] is that I landed 63 patches last year, down from 139 the previous year, which was way bigger than the 56 patches the year before. This was somewhat disappointing and I believe that partly it was due to the initial debugger landing the year before and general work on an immature code base at that time, which made progress much easier to happen in small chunks. I find that  I don't usually land separate patches for the same bug, so at least the number of commits is closer to the number of distinct bug reports or new features, than just individual code changes. Another reason for the decrease is that I spend significant time prototyping things that haven't landed yet, like the memory and performance widgets. Also, lately I find myself diving into SpiderMonkey and Gecko work for our upcoming memory and performance tools, and my lack of experience there slows me down considerably. Nevertheless, this is something that bothers me and I intend to improve upon this year.

The second observation [2] is that I'm doing more reviews as time passes, which is to be expected I guess. Last year I did 240 reviews, compared to 220 reviews the year before and 25 reviews in my first year. Obviously those who are around longer get to do more reviews than those who are new to the project, but what I mostly find interesting about this is that I get to do approximately one review per working day. Since I'm counting these from commit messages, they don't take into account the back-and-forth between the patch author and reviewer while shaping up the patch. I counted 372 review requests in my email during the past year (not including feedback or needinfo requests), so I seem to be giving reviews or feedback more like twice a day, every day. This must have contributed in part to the diminished number of patches that I landed myself, but on the flip side I get more visibility in incoming changes and can be more up to speed on my own work, which should decrease the turnaround for reviews on my patches. In addition to that, when I'm doing a review I'm looking at the patch from many different angles (from code correctness and code style issues, to API clarity and architectural direction) and that gives me insights into how our architecture should evolve, which in turn results in more followup work (incidentally, I've filed precisely 100 bugs last year).

Another very important realization is that even if I had spent exactly zero time reviewing other people's work, it would have been very unlikely that I could have managed to land all those 303 patches myself (240 plus 63 of my own). Which is another way to say that we all make a bigger impact by enabling others to do better work, than by strictly fine-tuning our own work output. This is particularly important for achieving a high bus factor for the project, but it is also a necessary ingredient if we want to nurture a community of contributors that will keep the project successful in the years to come. I find this sufficiently important and motivating that I don't plan to be doing less reviews, just try to invest my time more efficiently. We'll see how that goes.

Speaking of nurturing new contributors, I saw in a relevant dashboard that I mentored 8 bugs from 6 new contributors. I'm not sure about the time period of that data, but I've only heard about this dashboard recently, so I assume it should be relevant to this post. Clearly I need to do better in that department.

This past year I've also invested more time in giving public talks and helping with the Firefox OS launch in Greece. The social aspect was extremely rewarding and I've met a ton of great people, so I'd like to do more of that. Not sure how I could combine this with increased code productivity though.

All in all I feel it was a good year and I can't wait to see what the future holds. Onwards!


[1]: I used this command to count my patches (omitting the wc invocation allowed me to inspect the commit messages):
hg log -u past@mozilla.com -d "2013-04-26 to 2014-04-25" --template '{date|isodatesec} : {desc|strip|firstline}\n'|wc -l

[2]:I used the following command to count my reviews. Clearly searching for the right strings is a work of art:
hg log -d "2013-04-26 to 2014-04-25" -k ",past" -k "r=past" -k "r=panos" -k ",panos" -k "r=pastithas" -k ",pastithas" --template '{date|isodatesec} : {desc|strip|firstline}\n'|wc -l