Closed Bug 639802 Opened 13 years ago Closed 13 years ago

Partial auto-updates for chemspill releases

Categories

(Release Engineering :: General, enhancement, P5)

Product:
Release Engineering
Component:
General
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 575317

People

(Reporter: mozilla, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110107 Iceweasel/3.5.16 (like Firefox/3.5.16)
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110107 Iceweasel/3.5.16 (like Firefox/3.5.16)

Dear all,

this is a feature request regarding the handling of auto-updates in case of a chemspill release (e.g. 3.6.14 to 3.6.15).

I am an administrator of a primary Mozilla mirror, serving roughly 40 TByte a day in times of a Firefox update.

When a chemspill release is distributed, this is done in the usual way: a complete upgrade ".mar" file is provided, in addition to a partial update from the previous version. Because a chemspill release naturally occurs only a few days after the release of the previous version, the percentage of Firefox users that already upgraded to the pre-chemspill version is very low.

Based on my numbers (from mozilla.ftp.halifax.rwth-aachen.de, logs from yesterday) only about 18% of all requests are directed to the partial update. In other words, by providing an additional update file from 3.6.13 to 3.6.15, a lot of traffic (and related resources) could be saved (consider the size difference of the partial and the complete update file!).

Considering the effort that is needed to handle even a non-chemspill Firefox update, we as a Mozilla mirror would be very happy to see Mozilla take away some of our burden here.

Summary: Please provide partial update files skipping two versions in case of a chemspill release.

Best regards,
Carsten Otto

Reproducible: Always
OS: Linux → All
Hardware: x86_64 → All
Moving to releng, as that's probably going to get greater visibility with the relevant people.
Component: General → Release Engineering
Product: Firefox → mozilla.org
QA Contact: general → release
Version: unspecified → other
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ideally, we'd provide partials for more past releases in all cases, not just in chemspills. It's not trivial to do this with our current update system/scripts. Bug 583244 tracks a fairly major upgrade which will make one part of this easier.

I don't think we want to develop for this specific scenario but once AUS3 is in play there's a couple different ways to go about this:
- Generate updates for N past releases in all cases, where N is configurable at start of the release process
- Generate partials on demand, and cache them.

There may be other options, but the latter is something we've talked about doing for a long time.

cc'ing others who may have input.
Depends on: balrog
Priority: -- → P5
This is a dupe of bug 575317, right?
Yes, indeed!
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Yes (sorry for that), but the original bug report does not mention the order of magnitude for this problem (my mirror/university really is suffering right now!) and does not address the special problem a chemspill release poses.
I understand why this is difficult for you, but I don't think this is going to make it happen any faster. As a workaround, can I suggest that you have IT lower your rating either permanently, or right before a chemspill? This should reduce your overall traffic.
We are in direct contact with the corresponding admins to tune the traffic (weight). However, I'd like to see this problem solved as described.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.