If you look at about:buildconfig on any mozilla-* hg based application, it has the latest revision of mozilla-central (or mozilla-1.9.1) code that was used to build that application. This is valuable for QA because if a regression occurred between two builds, we can get exact source revisions. We should find a way of integrating the comm-central revision into the generated about:buildconfig.

This is tricky because buildconfig.html is generated statically at build time. You can think of the extreme case here as your app running on XULRunner, where the two builds are completely separate. We might be able to figure out a way to allow buildconfig.html to include another file that you could ship with your app. I'm not sure how we'd do it, but something like an overlay or an included frame might work. CCing mfinkle, as I bet Fennec would like this too.

Just speculating wildly, if we could set a pref like "app.buildconfig.url", and then have buildconfig.html include that as a frame, that would work (but I'm not sure that about:buildconfig has chrome privs, and I'm fairly sure if it doesn't we don't want it to.)

I thought that had been filed already, but it may be in the SeaMonkey product, not sure.

Oh, by the way, if we have have application.ini state one repo/revision and platform.ini another, can't we make buildconfig.html display both? Still, we're also displaying the configure info from Mozilla and not the info handed to the "original" configure of comm-central, which results in a nasty string with duplicated options, etc. I think that one's harder to get right.

Oops, yeah, you totally filed this already.

(In reply to comment #4) > Still, we're also displaying the configure info from Mozilla and not the info > handed to the "original" configure of comm-central, which results in a nasty > string with duplicated options, etc. I think that one's harder to get right. That part is bug 444022. V.Duplicate