Closed Bug 306864 Opened 19 years ago Closed 18 years ago

On nightly channel, AUS advertizes update to next build instead of latest build

Categories

(AUS Graveyard :: General, defect)

Product:
AUS Graveyard
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
4.x (triaged)

People

(Reporter: darin.moz, Assigned: morgamic)

References

Details

AUS advertizes update to next build instead of latest build. I noticed that when I query AUS2 for an update from a build that has a corresponding partial update available, the update is to the next available build, which may not be the same thing as the latest available build. If I then query AUS2 for an update from a build that does not have a corresponding partial update available, then the update is to the latest available build. Of course, for most users there should be a partial update available, so this inconsistency is really not a problem. I'm filing this bug because I think we want AUS2 to serve updates to the latest build instead of just to the next build. If this means only serving complete updates in such cases, then I think that's okay (even though two partial updates may be smaller in size than a complete update). I think this bug will mostly just impact nightly build testers, who have been away from their computer for a few days, as they will then have to cycle through several updates before they arrive at the latest build. Of course, it could also be an issue if we ever released multiple security updates in a short time span.
This bug is based on an interpretation of how we intend to use the "nightly" channel. I have interpreted it to mean "update my client to the next nightly." You appear to want "nightly" to mean "update me to the latest nightly." Current behaviour is by design. I'm not convinced it needs to be changed. Consider: a) Things work pretty well right now aside from this debatable behaviour. b) We need software update testing. Updating users to the latest build will not allow them to test partial update if they take longer than a day to update or download a build from two days ago and update. c) Applying multiple partial patches serially without restarting the client between patches will require the server to understand the series of build IDs. This functionality isn't the client, yet, but the server is approximately there. d) We need to spend our time on other AUS features before beta/release -- like static XML file generation and ensuring locales update seemlessly. (In reply to comment #0) > I think this bug will mostly just impact nightly build testers, who have been > away from their computer for a few days, as they will then have to cycle through > several updates before they arrive at the latest build. Of course, it could > also be an issue if we ever released multiple security updates in a short time span. Bug 306864 (this bug) wouldn't impact an audience that is only receiving security updates for releases. AUS works in a different way for nightly builds as it will work for beta and full releases. Depending on our resources during the major releases, patches may either be present for 1.5 -> 1.5.1 then 1.5.1 -> 1.5.2 or 1.5 -> 1.5.2.
That's not how we originally discussed it. Maybe temporarily it's ok if we really want to get a lot of testing of partial updates, but the normal behavior should definitely be to get us to the newest available build, using a partial update if available, and serving a complete update otherwise. This is going to be very important when we get to the Firefox 1.5.2 timeframe.
(In reply to comment #2) > This is going to be very important when we get to the Firefox 1.5.2 timeframe. "None of the current nightly channel automation will apply to Firefox 1.5.x."
3 people in the office agree that nightlies should update to the latest build. This is hell on a stick.
Assignee: nobody → chase
Summary: AUS advertizes update to next build instead of latest build → On nightly channel, AUS advertizes update to next build instead of latest build
Chase: I agree with you that this is low-priority, especially given that it only applies to the nightly updates. I did not realize that you had other plans for the official releases. I agree that other things like supporting l10n is definitely higher priority than this. It might make sense for the client to have a hidden pref that can be set to force selection of complete updates in case someone doesn't want to iterate through 7 partial patches in order to get their week old nightly build up-to-date :-)
->ASSIGNED (see bug 305642 for where verifying binary patching works as expected was originally filed)
Status: NEW → ASSIGNED
Blocks: 306999
This is by no means a high priority (hey, it's nightlies after all ;) But just wanted to point out another side effect of this that I noticed. On occasion (somewhat frequently actually) there is more than one build posted on the same day. The automatic check for updates only fires once a day. If you only ever install when the automatic check prompts you, you'll wind up 2 or 3 days behind in the course of a week.
*** Bug 309260 has been marked as a duplicate of this bug. ***
So what is the plan for the release versions for updating when there are "missed" updates? There might be more elegant solutions than just making the user download the full installation file. From my newsgroup post today (n.p.m.seamonkey): *Possible Solutions* 1. Create and store incremental update files for multiple older versions. So if the most current version is 1.0.7, have update files that will update (in one step) to 1.0.7 from 1.0.6, 1.0.5, 1.0.4, etc., all the way back to either the origin of the update system, or to where x% (99%?) have already updated, or to however much storage capacity mozilla.org's servers can hold. Then offer whatever single update file that user needs to get to the current version. 2. Make the updater *automatically* and in *one step* update from 1.0.5 to 1.0.6, then from 1.0.6 to 1.0.7. The updater would download all needed update files and install them one-after-the-other (without requiring user interaction). This would avoid having to create update files for numerous combinations of update scenarios (suggestion #1), but would involve enhancing the current updater. Of course if filesize of the sum of all incremental updates is greater than a full update, then get the full update. The server should check this. BTW-1: For nightlies: It would be nice if the updater showed which nightly it was updating to (i.e. the date). (relevant for nightly build testers only) BTW-2: Why does the updater say "Firefox/Thunderbird _may_ check periodically for new updates"? It would be better if the dialog checked the pref: [x] Auto check for updates) and said "_will_ periodically check..." or "is currently _not set to_...".
*** Bug 310245 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > 3 people in the office agree that nightlies should update to the latest build. Something simple, perhaps, for now at least: As the last step of each update: - check for any further pending updates (whether incremental/"nightly" or official releases). My Mac seems to do this now for its "Software Update...", and I Like It! Thank you, Eddie Maddox
*** Bug 311206 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > As the last step of each update: > - check for any further pending updates > (whether incremental/"nightly" or official releases). In my mind this is a pretty weak design solution, as a user could end up spending an awful lot of time looping through restarts if they're several updates behind (ie: gone on vacation, etc). Also, we need to talk about the relative effort here in terms of getting a solution that works under nightly-update use-cases vs. release-update use-cases. For release updates, I'd love it if we could get delta update .mar files to cover the 1.5.0 -> 1.5.x case (proposal #1 from comment 9) or at the very least have the updater download all steps of the incremental updates and then apply them sequentially before restarting (proposal #2 from comment 9). For nightlies, however, proposal #1 seems unweildy, as after a month we'd be looking at 30 different update files to support nightlies from the previous 30 days.
(In reply to comment #13) > For nightlies, > however, proposal #1 seems unweildy, as after a month we'd be looking at 30 > different update files to support nightlies from the previous 30 days. Proposal #1 also includes: "Of course, if filesize of the sum of all incremental updates is greater than a full update, then get the full update." (although I wrote it separately) We could even say if the inclementals are >50% of a full update, then do full (because multiple incrementals have extra overhead and risk). It shouldn't be too hard to estimate (for fun) how many days until Mozilla switched from incremental to full (yes, this would be a *changing* *estimate*).
I'm not sure where in this bug Darin says that we'll be supporting applying multiple partial patches easily. Until we do that, it will not be better for the nightly channel to offer multiple partial patches in order for a client to get to the latest nightly. We'll fix this by setting some standard number of builds for which partial patches to the latest build will be created. Beyond that number of builds, a complete update will be used to go to the latest build. Example: * ... back when disco ruled * 2005100108 -- complete -> 2005100508 * 2005100208 -- partial -> 2005100508 * 2005100308 -- partial -> 2005100508 * 2005100408 -- partial -> 2005100508 * 2005100416 -- partial -> 2005100508 * 2005100508 -> no updates The number of builds we'll create partial patches for to the latest build will most likely be 5. Because Chase likes 5 more.
We have no plans to modify the client to support applying multiple partial patches. I'd argue that it isn't worth the effort. I really like Chase's idea of a sliding 5 day window for partial patches :-)
(In reply to comment #16) > We have no plans to modify the client to support applying multiple partial > patches. I'd argue that it isn't worth the effort. > > I really like Chase's idea of a sliding 5 day window for partial patches :-) I had that same idea, but never suggested it because it seemed fine at first untill I realized that perhaps the same would have to be done for each localization.
(In reply to comment #17) > I had that same idea, but never suggested it because it seemed fine at first > untill I realized that perhaps the same would have to be done for each localization. Yup, this will have to be done for each localization, each product, each platform, each version, and for N builds where N=5. Since that's a hell of a lot of builds to compute partial patches, it's why I chose to implement the way it works right now. Did I mention that N=5? 5 is so cool.
How about starting out with N=1 then? poke, poke,... nudge, nudge ;-)
I know nothing about how patches are calculated, but some method should be developed to remove the possibility of version creep. This is what happened to me. By the time I filed a bug I was 9 days behind. I had no idea that this ever occured until my bug got marked a duplicate of this one.
(In reply to comment #18) > Did I mention that N=5? 5 is so cool. 5 is, like, *totally* my favourite number. r=me!
(In reply to comment #18) > Did I mention that N=5? 5 is so cool. While I agree that 5 is a pretty cool number, I would like to suggest 7 (days). This would enable the numerous "casual" testers to update once per week (e.g., every Monday) and still be able to test/use the partial update feature. Of course, if "n" is the number of *builds* and not the number of *days*, then "n" needs to be an estimated value to achieve the desired number of days (e.g., 9). *Calculation of Number of Builds (nightlies only)* Products = 6 (Fx, Tb, Suite, Calendar, Camino, Composer) Platforms = 3 (Win, Mac, Linux) Versions = 3 (trunk, 1.0.x branch, 1.5.x branch) Languages = 1 (only Englich for nightlies?) n = 7 (to allow weekly updating) ---------------------------------------- TOTAL = 378 update files (Yikes! Doable?) Alt. TOTAL = 189 (Fx, Tb & Suite Only) Alt. TOTAL = 135 (Fx, Tb & Suite Only; and n = 5)
*** Bug 311355 has been marked as a duplicate of this bug. ***
Forgive me if I'm being dense, but I don't see any discussion about what's actually going to happen when you update. wHEN THIS BUG IS FIXED, if I have a 20051005 nightly and I don't check for an update until 10/9, am I going to have to go through the process 4 times?
(In reply to comment #24) > to go through the process 4 times? No. Please see comment 9, comment 13 and comment 15. Everyone's on board with the design goal of making it so that a single click on "Check for Updates ..." results in FFx being brought up to the latest available version (as dictated by the update channel).
How expensive is it in terms of bandwidth and cpu to produce binary patches? If it's not going to put major stress on AUS, theoretically the system could generate an (older) update as requested by comparing the user's current build to the latest. That patch could then be retained for however long is deemed suitable.
*** Bug 306999 has been marked as a duplicate of this bug. ***
(In reply to comment #26) > How expensive is it in terms of bandwidth and cpu to produce binary patches? If > it's not going to put major stress on AUS, theoretically the system could > generate an (older) update as requested by comparing the user's current build to > the latest. That patch could then be retained for however long is deemed suitable. The trouble with that is that there are any number of combinations of builds that people could have, giving you a seemingly endless number of new builds to be generated. This would simply not be feasible as you would then need an entire new set of tinderboxen working purely on generating patches. Patch generation is not instantaneous either and the system would not be able to keep up with the demand for .mar files.
Isn't the patching mechanism flexible enough for progressive patching? I know commercial systems like RTPatch allow you to make patches for multiple versions in one patch. Seems to me that a patch should roll up all previous patches up to a certain point.
A trivial possibility would be if each build could generate incremental updates for several (but not all) previous builds, and the updater could do the update in few steps. Example: - Each build make incremental updates from the last 7 days, one for 14 days ago, other for a month ago, one for 3 months ago. So, only 10 incremental files are created. - If we try to update a build from 40 days ago, intead of 40 downloads/relaunch, the updater could download and apply the month update, the week update and the 3day update. So, only 3 downloads/relaunchs. - If we try to update a build from 20 days ago, the updater could download the 14days update and the 5days update. Only 2 downloads/relaunchs.
Comment #15 explains what we are actually doing to resolve this bug. Unless you think there's something wrong with that, please hold from discussing alterate approaches. Thanks.
Also, updater can rollback to previous version (starting version, allways same version). Then, download patch, which will patch system to nightly build and start browser in new working version. Then new patch will become available updater will again rollback browser to starting version and apply patch. Only one download is needed. Starting version can be changed to minimise size of updates. Server part of update system should know which starting version want patch and give link to updater for work.
*** Bug 318778 has been marked as a duplicate of this bug. ***
Why there is no "vote for"-button in this product?
Flags: blocking1.8.1?
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build
Status: ASSIGNED → NEW
I wonder if a simpler solution to this problem would be to have the client download the full update whenever there are multiple partial updates available. It would cost more bandwidth, but only for the 1% case (assuming most updates are from one release build to the next one), and I suspect it would be much more feasible to implement than setting up the build system to generate five days worth of partial updates for nightlies.
Myk, couldn't you help fix this bug on the server? Chase's plan seems like it is the best solution, but an even simpler solution would be to implement the logic of only advertizing a complete archive when the client is more than one step behind the latest build. Unfortunately, I can't see the AUS code, but you can ;-) Maybe it would be easy to implement server side? Adding complexity to the client to work around the server behavior seems like a big mistake to me. The update system is extremely critical, and we don't want to increase the complexity of the client anymore than we have to. So long as the update service is working, we can make changes to the client. But, if the update service breaks, then we are screwed. Let's keep the client as simple as possible! :-)
> Myk, couldn't you help fix this bug on the server? Chase's plan seems like it > is the best solution, but an even simpler solution would be to implement the > logic of only advertizing a complete archive when the client is more than one > step behind the latest build. Unfortunately, I can't see the AUS code, but > you can ;-) Maybe it would be easy to implement server side? Actually I can't access the production servers anymore, as I'm no longer a sysadmin, but you may well be right about this being easier to implement on the server side, and your point about the relative dangers of horking the server vs. the client is well-taken. I'll take a look at the aus2 code and see if I can figure out what it would take to fix this server-side.
That's awesome, myk! Thanks. I bet preed and coop will appreciate your help with this!
For what it's worth, I recently wrote an extension that hacks around this problem by repeatedly installing updates for you automatically: http://www.melez.com/mykzilla/2006/03/easier-updating-to-latest-nightly.html You might try it while waiting for this bug to get fixed.
Myk has worked on a patch for the AUS2 code that will skip partial updates if they are too far away and instead jump to a complete update that points to the latest build. We need to test this further -- so we set up aus2-dev to run some preliminary tests. Could some of you help us test this? Here is what you could do: a) download an older build, change the domain in your app.update.url to aus2-dev.mozilla.org:7777 instead of aus2.mozilla.org b) see if the behavior works correctly -- do you get the correct update? c) do the same thing with the next-to-latest build and see if you do get a partial update
> a) download an older build, change the domain in your app.update.url to > aus2-dev.mozilla.org:7777 instead of aus2.mozilla.org This is best accomplished by setting app.update.url.override (via about:config) since changes to app.update.url will be ignored unless you modify firefox.js in the application folder.
Downloaded Deer Park 1.6a1 20060322 Verified app.update.channel: nightly Added in a new app.update.url.override: https://aus2-dev.mozilla.org:7777/update/1/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/update.xml Results when clicking on "Update Now" There were problems checking for, downloading or installing this update. Deer Park could not be updated because: AUS: Update XML File Malformed (200)
All nightly trunk builds from 3/22 through 3/26 suffered form an issue where any files they downloaded were corrupted. Therefore it is not possible to automatically update any of these builds because the update cannot be downloaded correctly. This is not related at all to the issues in this bug. What you are seeing is bug 331453. You will have to download a 3/27 or later nightly build in order for updates to install correctly.
I dont think this works/is beeing testable right now since Update-system is dead since over a month (and has not only that one Bug you mentioned)? Anyway, tested with same setting and new build without that Bug: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060327 Firefox/1.6a1 ID:2006032710 Same AUS: Update XML File Malformed (200) error...
I justed updated from a nightly build I downloaded yesterday to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060329 Firefox/1.6a1, and the update worked flawlessly. Partial updates seem to be working for me. How old of a build should I download to test the complete update feature in comment #41?
(In reply to comment #45) > I dont think this works/is beeing testable right now since Update-system is > dead since over a month (and has not only that one Bug you mentioned)? > > Anyway, tested with same setting and new build without that Bug: Mozilla/5.0 > (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060327 Firefox/1.6a1 > ID:2006032710 > Same AUS: Update XML File Malformed (200) error... > I just downloaded this build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060327 Firefox/1.6a1 ID:2006032705 Did a Help -> Check for updates ... etc. and was successful updating to: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060328 Firefox/1.6a1 ID:2006032807 and repeated the above and updated to: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060329 Firefox/1.6a1 ID:2006032905 I have no idea what this 2006032710 build you downloaded is. There was no 2006032710 official trunk nightly.
(In reply to comment #46) > I justed updated from a nightly build I downloaded yesterday to Mozilla/5.0 > (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060329 Firefox/1.6a1, and > the update worked flawlessly. Partial updates seem to be working for me. > > How old of a build should I download to test the complete update feature in > comment #41? > The oldest windows cairo trunk build which you can download from which updates should work is here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-03-27-06-trunk/ However, my experience is that after modifying app.update.url as outlined in comment #41 it still requires 2 updates to get to todays build.
(In reply to comment #47) > I have no idea what this 2006032710 build you downloaded is. There was no > 2006032710 official trunk nightly. > Apparently the link to Nightly in Thread of Peter(6) was wrong and I therefore unknowingly picked an Hourly. Now tested with ID:2006032705 but following comment #42 and setting app.update.url.override and NOT normal setting app.update.url still gives AUS error. Only when modifying app.update.url (and not app.update.url.override or firefox.js), update begins to work! 594 kB are downloaded but on next start, it's still ID:2006032705 and the "Software Update" Windows is opened and says there is an Update available. Clicking on ok hangs Update forever (Connecting to update server...). Deleting active-update.xml etc. and doing the same again but dont click anything on Software Update Window, closing everything, Check for Updates tries an partial and then full Update. But that one still doesnt work.
Trying to update Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060404 Firefox/1.6a1 with app.update.url.override set to https://aus2-dev.mozilla.org:7777/update/1/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/update.xml still results in the error message: AUS: Update XML File Malformed (200) I tried several different Firefox versions from 03/30 to 04/04 with the same results. With the 04/04 build, changing only app.update.url to the above URL results in a message that there are no new updates available. The partial update (with app.update.url.override and app.update.url reset) is still working perfectly.
Hmm, a problem with my patch is that it doesn't work if there's a break in the chain, i.e. if a nightly doesn't get built for a couple days and then gets built without generating meta-data for upgrading from the previous nightly. Perhaps a better solution is to upgrade to the build with the highest build ID.
I think the XML malformed error is caused by problems with the https certificate for aus2-dev.m.o (which is actually on chameleon.m.o). If you manually retrieve something like https://aus2-dev.mozilla.org:7777/update/1/Firefox/1.6a1/2006032705/WINNT_x86-msvc/en-US/nightly/update.xml using the address bar you get a bunch of errors: 1, Certificate expired 18/02/06 (-> Continue button) 2, "Unable to verify identify of chameleon as trusted site" - self issued certificate ? (-> Accept temporarily or permanently, Ok) 3, Domain mismatch between aus2-dev and chameleon (-> Ok) Valid looking update information then shows, and subsequent "Help > Check for updates" also finds and downloads a complete update. It doesn't apply though, just restarts quickly with unchanged buildid. I suspect this is some separate VC8 library problem, as I can apply the update successfully if I do it manually (see http://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file) with msvc{p,r,m}80.dll and Microsoft.VC80.CRT.manifest copied into firefox-update/.
Triaging out build bugs - reassigning to Mike M since this is in AUS code.
Assignee: build → morgamic
Status: NEW → ASSIGNED
Okay -- been doing some tinkering. Here are my notes: * It is possible to read the builds and sort numerically to determine the latest build id (readdir into an array, then sort -- should be cheaper than reading every snippet) * The snippets for the latest build id are null, as that signifies no future update for that latest build * Using the latest build id, we can traverse the directory to the last build before it and offer that complete update by default * In addition to this, we can offer a partial update if and only if the destination build in the partial snippet is equal to the latest build -- otherwise the partial patch will be ommitted and users will be forced to use the complete patch that takes them to the latest build In short, the behavior will be like this: * If a partial patch will not upgrade the client to the latest build, a complete patch will be used * All incoming update requests will always update to the latest build (not some point between) and will only require one update Any objections?
Sounds ideal to me, though I have a fast net connection and I'd be just as happy to do without partials at all ;)
Thounds much better than todays behaviour. Does this also take care of situations, where no updates are installed even though there are available (the 20050519 build for example always updated to itself and didn't really install anything new)?
(In reply to comment #56) > Thounds much better than todays behaviour. Does this also take care of > situations, where no updates are installed even though there are available (the > 20050519 build for example always updated to itself and didn't really install > anything new)? If we circled around the latest updates, things would heal themselves as new updates were pushed. Also, attention to the destination build would ensure that 20050519 -> 20050519 wouldn't be possible. So yes, I believe this would also take care of that particular issue.
Alright, finished patching this. Here is an output comparison between production and the patched version for 1-off's and 3-off's: https://update-staging.mozilla.org/~morgamic/sanity/reports/20060525175403.html This is set up on stage, so you can test it: https://aus2-staging.mozilla.org:8711/ I plan on doing some more regression testing to make sure we don't get unexpected output for other permutations of app.update.url parameters. If everything checks out, we should be able to push this on Friday.
WFM updating Win Trunk & 1.8.0 branch from 2006052205 to 20060525, once you get around the certificate issues. I'm surpised though, preed/rhelmer had to use identical complete & partial updates for the older Firefox 1.5 releases. Eg https://aus2.mozilla.org/update/1/Firefox/1.5.0.1/2006011112/WINNT_x86-msvc/en-US/release/update.xml This was to work around some client side problem I think. Perhaps they can remember the details.
I tried testing this with the 2.0 branch and it didn't work. I changed app.update.url to the url you listed, is that all I had to do?
(In reply to comment #60) > I tried testing this with the 2.0 branch and it didn't work. I changed > app.update.url to the url you listed, is that all I had to do? Nevermind, found what I did wrong, it works great except for the certificate issue.
All - we plan on releasing a patched AUS after the release traffic tapers off. The fix will happen within the next week, and has already been tested on aus-staging using the aus sanity tests along with some user feedback. We will keep you guys up to date through this bug and also send out an announcement regarding the open-sourcing of AUS. Thanks to everyone who helped test the new patch! :)
(In reply to comment #62) > and also send out an announcement regarding the open-sourcing of AUS. Mike, where will you be sending this announcement?
(In reply to comment #63) > Mike, where will you be sending this announcement? Not entirely sure -- but it'll at least be on planet and on this bug. The build guys will know better places to post. :)
*** Bug 341624 has been marked as a duplicate of this bug. ***
So we have good news and bad news. Good news first: Infra helped us out and pushed/migrated AUS2 code to a more secure and reliable location. The migration also meant that the most recent code is getting pulled from staging, which includes the fix for this bug. And the bad news: Due to recent mirror changes, the "latest" updates for nightlies are pointing to a .mar file that doesn't exist -- a result of the restructuring of our mirror images. We plan on resolving this ASAP. Please see bug 341752. When the reconfiguration is complete, nightly updates will be restored and also point to the latest complete for builds that are more than one partial away from the latest build.
Depends on: 341752
Looking good now that we have some updates working again. The changes here also fixed bug 314189, by returning a complete update for any build date that doesn't have a partial to the latest build. There will be some third party builders who are using 'ac_add_options --enable-update-channel="nightly' and will be bitten by this, but shame on them for blatently copying a mozconfig from the tinderbox without understanding what it does.
This is fixed, isn't it? (In reply to comment #66) > ... nightly updates will be restored and also point to > the latest complete for builds that are more than one partial away from the > latest build.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
QA Contact: nobody → general
(In reply to comment #68) > This is fixed, isn't it? > > (In reply to comment #66) > > ... nightly updates will be restored and also point to > > the latest complete for builds that are more than one partial away from the > > latest build. > Not completely: Bugzilla Bug 344676 AUS Partial Update System Partially Broken (Full update instead of binary partials)
You need to log in before you can comment on or make changes to this bug.