Add pushlog feature to beta builds #51

Closed
whimboo opened this Issue Mar 24, 2012 · 12 comments

Comments

Projects
None yet
3 participants
@whimboo
Contributor

whimboo commented Mar 24, 2012

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

This comment has been minimized.

Show comment
Hide comment
@xabolcs

xabolcs Mar 24, 2012

Collaborator

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().

Collaborator

xabolcs commented Mar 24, 2012

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

This comment has been minimized.

Show comment
Hide comment
@whimboo

whimboo Mar 26, 2012

Contributor

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.

Contributor

whimboo commented Mar 26, 2012

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

This comment has been minimized.

Show comment
Hide comment
@whimboo

whimboo Mar 26, 2012

Contributor

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

Contributor

whimboo commented Mar 26, 2012

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

@xabolcs

This comment has been minimized.

Show comment
Hide comment
@xabolcs

xabolcs Mar 26, 2012

Collaborator

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?

Collaborator

xabolcs commented Mar 26, 2012

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

This comment has been minimized.

Show comment
Hide comment
@whimboo

whimboo Mar 26, 2012

Contributor

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.

Contributor

whimboo commented Mar 26, 2012

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

This comment has been minimized.

Show comment
Hide comment
@xabolcs

xabolcs Mar 26, 2012

Collaborator

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. :)

Collaborator

xabolcs commented Mar 26, 2012

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

This comment has been minimized.

Show comment
Hide comment
@whimboo

whimboo Mar 26, 2012

Contributor

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.

Contributor

whimboo commented Mar 26, 2012

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

This comment has been minimized.

Show comment
Hide comment
@xabolcs

xabolcs Mar 27, 2012

Collaborator

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.

Collaborator

xabolcs commented Mar 27, 2012

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

This comment has been minimized.

Show comment
Hide comment
@whimboo

whimboo Mar 28, 2012

Contributor

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

Contributor

whimboo commented Mar 28, 2012

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

@xabolcs

This comment has been minimized.

Show comment
Hide comment
@xabolcs

xabolcs May 25, 2012

Collaborator

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

Collaborator

xabolcs commented May 25, 2012

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

xabolcs added a commit to xabolcs/nightlytt that referenced this issue Jun 4, 2012

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!
@xabolcs

This comment has been minimized.

Show comment
Hide comment
@xabolcs

xabolcs Oct 15, 2015

Collaborator

This is the original beta pushlog issue.

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

Cc @whimboo, @Cai0407.

Collaborator

xabolcs commented Oct 15, 2015

This is the original beta pushlog issue.

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

Cc @whimboo, @Cai0407.

@xabolcs

This comment has been minimized.

Show comment
Hide comment
@xabolcs

xabolcs Oct 17, 2015

Collaborator

Fixed by the commit 60e1ba7 above.

Collaborator

xabolcs commented Oct 17, 2015

Fixed by the commit 60e1ba7 above.

@xabolcs xabolcs closed this Oct 17, 2015

UtiluMark added a commit to UtiluMark/nightlytt that referenced this issue Nov 6, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment