Add pushlog feature to beta builds

[whimboo]

I think that we should also add the pushlog feature for beta builds. Those people are also testers and for us it would be good to know what has been checked-in between beta releases.

[xabolcs]

How do you define: beta builds? Or how do you define: release builds?

Supporting beta builds in pushlog feature obsoletes nightlyApp.repository and "renames" nightly.isTrunk().

[whimboo]

Beta is: http://www.mozilla.org/en-US/firefox/channel/
Repository: https://hg.mozilla.org/releases/mozilla-beta

It gets new builds each week and it would be pretty helpful to see the changes in-between those.

I would rename nightly.isTrunk() to nightly.isTestChannel(). nightlyApp.repository would have to be expanded.

[whimboo]

Well, we could probably even do this with release builds if this change is easy enough.

[xabolcs]

whimboo commented

Well, we could probably even do this with release builds if this change is easy enough.

Change would be easy, but the benefits are doubtful. :(
Are You sure about giving a 1+ month timerange based pushlog (for example: 10.0.2 -> 11.0) to Release users?

[whimboo]

Why not? Would be a good start for hunting down regressions. Having a list of all patches would help us a lot to quickly search through all of them to find possible regressing ones. The changelog in-between major releases can be huge but I can clear see benefits especially for point releases like on the ESR branch. Gotcha... one more branch we could/should track because it has nightly builds.

[xabolcs]

Why not? ...

Because my connection resets if I try to download the pushlog linked above. :)

We could track the release if we wouldn't DoS hg.mozilla.org with those links.
Limiting the enablement of pushlog menuitem based on the saved changesets time range would be nice.

As You said other "channels" are welcome: for example nightly-ux. :)

[whimboo]

Do you have such a query which times out for you? I would be interested in.

Regarding the channel I think we can make it dynamic by reading in the currently used repository from application.ini or even via a service. That way we wouldn't have to maintain our own list and could expand the pushlog feature to all available branches.

[xabolcs]

After some pm with whimboo about this timeout problem we decided to

• warn the user if he/she tries to open a probably long pushlog (for example a changelog in-between major releases)
• long pushlog == prevChangeset is too old ~ (almost equal) the latest successful update is too old
• date of latest successful update could be retrieved from NsIUpdateManager
• to decide what constitutes old, a preference is added - we should figure out a default value.

If we would like to improve reliability we could parse nsIUpdate's buildID up to day precision.

If for some reason the NsIUpdateManager is not available we could decide to store the previous buildID along with prevChangeset.

[whimboo]

Thanks @xabolcs for the nice write-up. This sounds like a good plan.

[xabolcs]

Rapid Betas should be tracked.
Therefore it would be nice to ship this before FF15 enters beta (at July 7, 2012).

[xabolcs]

This is the original beta pushlog issue.

A few years ago there was a timeout problem, now that was fixed.

Cc @whimboo, @Cai0407.

[xabolcs]

Fixed by the commit 60e1ba7 above.