Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Add pushlog feature to beta builds #51

Open
whimboo opened this Issue · 10 comments

2 participants

@whimboo
Owner

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
Owner

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
Owner

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
Owner

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

@xabolcs
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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

@xabolcs
Owner

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

@xabolcs xabolcs referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@xabolcs xabolcs referenced this issue from a commit in xabolcs/nightlytt
@xabolcs xabolcs Issue #61 - add pushlog-to-tip menuitem.
It's not hidden for non-nightly channels, beware the long pushlog!
See related Issue #51 for details!
c5a0789
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.