Did you miss the ability to look at our source code and figure out who’s working on what where? Thought that only github can do that?
Let me give you a sneak peek at what I’ve been hacking on over the weekend.
What’s the big picture of our mainline code development?
You can see the blue line of development along mozilla-central, and then branch points for the release branches, and now for beta (miramar), and aurora. That’s pretty broad, and intentionally so. If you’re interested in the back and forth on a changeset level, this is how the branch point of fx5 beta looks:
Why does it say aurora? Because hg doesn’t know what you’re looking for. I determine what was branched off of what by looking at pushes, wherever a particular changeset was pushed first, wins. As beta branched off of aurora later, you see that this was the branch of aurora at the time.
Sadly, you don’t see the more interesting detail, that after that branch, the developer tools branch merged. If the database in the backend was tracking our project repos, you’d see that.
Of course, there’s also an l10n side to this. I get many questions on what to merge and where and so, and it’s hard to see what ended up in which repo, and if things are different. Let’s follow one of the l10n repos at large:
There’s even more details on the rapid branches for this one, like so:
Many of the same landings, but with different hg changesets, and then a merge. That merge didn’t make it to miramar, though. Which is OK, that’s a one-off anyway.
Now that I wetted your appetite, bad news: Nothing of this is live yet. I’ll actually need to make a patch at least for the API in bug 659260, get review and get it live. Also, this is currently code that’s run as part of the l10n dashboard, which isn’t really intended to cover all our sources. If we want this at large, it’ll need liberation, and the resources that comes with that. The actual code is pretty easy to liberate, though.
And, graphs are made with protovis, including a custom Network-based layout to do DAGs.