Closed Bug 692436 Opened 13 years ago Closed 11 years ago

Latest hourlies of Firefox nightly are using "default" as the update channel

Categories

(Release Engineering :: General, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: ltsnow, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [updates])

Attachments

(1 file)

Attached file channel-prefs.js
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0a1) Gecko/20111006 Firefox/10.0a1 Firefox/10.0a1
Build ID: 20111006041758

Steps to reproduce:

I downloaded the latest hourly build (Mozilla/5.0 (Windows NT 5.1; rv:10.0a1) Gecko/20111006 Firefox/10.0a1 Firefox/10.0a1 ID:20111006041758).  This is the zipped version BTW.  


Actual results:

When you open the update channel you see that it is set to "default" instead of "nightly".  This is also true for various other hourly builds from 10/5.  The nightly build from 10/5 was OK.


Expected results:

Update channel should be "nightly"
Confirmed, but its not limited to zip builds.  I use hourly's almost all the time, and rarely a nightly build.  My about:config shows 'default' rather than 'nightly'.

Using build:
app.update.channel;default
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111006 Firefox/10.0a1
http://hg.mozilla.org/mozilla-central/rev/62ea504b378d
Status: UNCONFIRMED → NEW
Component: General → Build Config
Ever confirmed: true
QA Contact: general → build.config
Component: Build Config → Release Engineering
Product: Firefox → mozilla.org
QA Contact: build.config → release
Version: 10 Branch → other
I'm pretty sure this is a result of bug 558180. I think this is WONTFIX'able, though. I can't think of a use case for installing hourlies and wanting to get updated automatically. If you want nightlies, get a nightly. If you're downloading on-change builds, there's a specific reason you want to be on that build, right?
Some of us use hourly builds, and on occasion, knowing full well I will get a full push, will go to Help-Check for updates, and grab a nightly.  This serves some use in testing manually that the update system is still working.  

For those that do bisection to find regression range for bugs will use hourly's to do so, then we would have to download a 'nightly' to get back on track, otherwise testers are going to be confused why they are not getting updates, either manually or auto...
What Ben says makes sense generally, but like Jim says I mostly use nightly builds, but when there are a lot of fixes I often use hourlies.  This makes it kind of pain to have keep changing the channel.  But not a deal breaker for me.
(In reply to Ben Hearsum [:bhearsum] from comment #2)
> I'm pretty sure this is a result of bug 558180. I think this is
> WONTFIX'able, though. I can't think of a use case for installing hourlies
> and wanting to get updated automatically. If you want nightlies, get a
> nightly. If you're downloading on-change builds, there's a specific reason
> you want to be on that build, right?

Ben,

Just my two cents...

My use case is to download and install an hourly (.exe) over my regular Nightly installation either to test a bug fix that has just landed or because the hourly has a fix for a problem that affects the regular Nightly significantly to not want to use it. In the past, it was convenient that when the next day's Nightly build became available, I only needed to do a regular update and I was back on the regular Nightly with the desired bug patch in place.

With this in mind, it would be disappointing that hourlies would be built with the update channel set to "default" instead of "nightly" because of forcing the inconvenience of having to manually download/install the next day's Nightly to "restore" things to the way they were.
I can't think of a use case for downloading an hourly build and wanting to stick with that build for the next one to six weeks, which is what a setting of "default" for the channel implies. It's probably better for the user (and for Mozilla) if the user gets notified reasonably soon that there is a newer build available.

(When Firefox has fully implemented a silent update, it would probably be better if that doesn't happen after an hourly build is installed as you don't want to silently destroy a testing environment--but that's a topic for some other discussion.)
Attachment #565211 - Attachment mime type: application/octet-stream → text/plain
OS: Windows XP → All
Priority: -- → P3
Hardware: x86 → All
Whiteboard: [updates]
(In reply to Alice0775 White from comment #7)
> Regression pushlog:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=1ce1d59084e5&tochange=51d989ece4c5

Based on this, it looks like we would simply need to set ${MOZ_UPDATE_CHANNEL} to "nightly" in the env for our dependent builds if this is something we'd like to change.
So this will not get fixed?  I probably download an hourly maybe once or twice a week and run it side by side with nightly using  \Hourly and \Nightly folders and -no-remote -P on the same profile.  Sucks though that the installer won't know to install the hourly to my \Hourly folder by default.
Product: mozilla.org → Release Engineering
(In reply to [not reading bugmail] from comment #9)
> So this will not get fixed?  I probably download an hourly maybe once or
> twice a week and run it side by side with nightly using  \Hourly and
> \Nightly folders and -no-remote -P on the same profile.  Sucks though that
> the installer won't know to install the hourly to my \Hourly folder by
> default.

This is indeed the new way of things. I know it's inconvenient for some, but we've been living with it for quite a long time without issue now.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
QA Contact: mshal
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: