<< SeaMonkey Places Bookmarks Try Server Builds | The roads I take... | Weekly Status Report, W12/2010 >>

"Human-readable" Pushlog Feeds

As I'm trying to stay up-to-date with what's going on in the Mozilla source code, I've been reading bonsai in earlier times and them pushlog HTML pages (e.g. the mozilla-central page).

As my communication channels were growing and my becoming overwhelmed with the amount of things going on there as well as clicking around on HTML pages, I sometimes didn't look in for a day or two and couldn't remember where I stopped last time. Some day, and that was months ago, while thinking about this, I figured it would be much nicer if I could subscribe to that information in a feed reader and just mark read what I have seen. I had also figured that I'm faster reading/skimming through entries in SeaMonkey's feed reader than I am with reading HTML web pages.

So, after some weeks of thinking that it would be cool to do that, I finally went and wrote some PHP code that would get the info from hg.mozilla.org, put it in a local MySQL DB on my server and present it to me as a feed I could subscribe to. After using this for some time and refining it a bit, I am not only up-to-date with what's happening in the repositories I want to track, but also feel confident that the system works well enough to have others use it as well.

http://dev.seamonkey.at/pushlog lists all the repositories I'm currently tracking there, with the repository names being linked to those new feeds, while the HTML link points to the hg.mozilla.org pushloghtml page corresponding to this repository.

I intentionally didn't include the whole diff in the feed entry, it's being linked as the "article link", as I usually only want to look at the full patches quite rarely, but they are often quite large and I want to keep both the feed and what I pull from the hg server reasonably light in terms of traffic.
Also, the feeds are updates at most hourly - jobs for pulling new info are being set every hour, but the server lazily processes those jobs depending on the server load. And really, if you're looking at this too often, it probably distracts you from work anyhow. ;-)

If you have any suggestions for improvements, questions, or requests for other repositories to be added, please contact me.
Note though that this is my server and I created those feeds primarily for my own use - it's nice if they are helpful for others, but they most importantly need to fit my own use case.

Entry written by KaiRo and posted on March 28th, 2010 14:09 | Tags: Mercurial, Mozilla, Pushlog | 6 comments | TrackBack




from Frankfurt, Germany

Your feed certainly has advantages over the default feed provided by the hg.mozilla.org repositories. There's an alternative to that, though, also per repository: (e.g.) <http://hg.mozilla.org/comm-central/rss-log>. Concerning content that's all I need (I use Web Page mode instead of Summary). The only problem for me with those feeds is the low entry count which doesn't fit my purpose. If I'm AFK for a day or more (think holiday) and for example mozilla-central sees commits en masse close to a freeze date (or even any other day someone commits things in 20 parts at the same time) then I'll be bound to miss commits, maybe important ones. Does your solution overcome that problem or is that not an issue for you? I already thought about some kind of feed proxy that runs on a server and constantly collects/rearranges feeds, i.e. also while I'm away. But I didn't find anything and I'm too lazy to write it myself. :-/

Concerning your feeds: I like the idea of including the affected files in the summary (yay!) but the hg.mozilla.or rss-log IMO has a better Author field that includes both author name and email address, whereas your feeds redundantly include the author name in the title (so that usually less of the actual title is visible).
2010-03-28 16:59



I can surely work on adding an option for increasing the number of entries in there.

As for the author field, it's no duplication, there is a difference between the person who pushed, which is listed as the author in my feeds, and the person who the patch is from, who is listed in the summary.

Also, the normal Mercurial rss-log or atom-log does not order entries by push time but by commit time, which esp. in case of marges is completely out of line with when it appeared in the code people and buildbots pull and build.
2010-03-29 01:56


rev id
Please show the medium changeset id (e.g. 048fb26978db) rather than the short one (e.g. 39972). The short ones can differ between machines, e.g. after merges, so they're not appropriate for passing around.
2010-03-29 05:51


from Frankfurt, Germany

Of course I know about the difference between committer and author (sgautherie and me seem to be the primary SM checkin-needed executors) but I didn't realize you're using both in your feeds. Nice! I also very much appreciate you using push time ordering; I really dislike seeing new commits popping up in between old ones. I guess I'll switch to your feeds then. :-)
2010-03-29 11:04



The hex changeset is shown in the article URL, is that too little discoverable?
2010-03-29 13:12

Dan Mosedale

This is great!
I love being able to see the files affect; thanks!
2010-04-01 20:23

Add comment