Closed Bug 668518 Opened 13 years ago Closed 10 years ago

consider removing old releases from mozilla-releases

Categories

(Release Engineering :: General, defect, P3)

x86_64
Linux
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: bhearsum, Unassigned)

Details

(Whiteboard: [release][automation])

In #developers today Asa was wondering if we can remove old releases from mozilla-releases, because we apparently get a lot of downloads of them still. The current list is:
2.0.0.20
3.0.19
3.5.19
3.6.17
3.6.18
4.0.1
4.0
5.0b2
5.0b3
5.0b5
5.0b6
5.0b7

Some of them have no updates pointed to them (all of the 5.0 releases, 3.6.17). 4.0.1 has at least the older 4.0 betas (1-6) pointed at it, but 4.0 should be safe to remove.

2.0.0.20, 3.0.19, 3.5.19 and 3.6.18 all have the previous releases on their respective branches pointed at them, so we can't remove them completely. Asa suggested that maybe we can remove everything but the MARs, though. The rsyncd exclude rules might get a little verbose, but it'd be doable.

Filing to facilitate discussion before we do anything.
Oh, I actually already added removal lines for 4.0 and 4.0.1, so we don't need to worry about them here.
I'm seeing a somewhat shorter list:
2.0.0.20
3.0.19
3.6.18
5.0

2.0.0.20 and 3.0.19 are already only mar update files. 

Ben, did you already go through and clear out the list ? I put some notes in bug 667672 comment #1 about the timing for removing files from mirrors. Fine that 3.5.19 went that now that 3.5.x is pointing at 3.6.18 for updates, and it's a few days past 5.0/3.6.18 so 3.6.17 and 4.0.1 could go.

More generally, limiting what's on the mirrors helps with direct downloads. All old links to download.m.o still work though, and some websites post those. Something like bug 652789 might be a way forward there.
(In reply to comment #2)
> 2.0.0.20 and 3.0.19 are already only mar update files. 

Only win32 update files, at that.
(In reply to comment #2)
> Ben, did you already go through and clear out the list ? I put some notes in
> bug 667672 comment #1 about the timing for removing files from mirrors. Fine
> that 3.5.19 went that now that 3.5.x is pointing at 3.6.18 for updates, and
> it's a few days past 5.0/3.6.18 so 3.6.17 and 4.0.1 could go.

As far as I remember, I only added 4.0 & 4.0.1.
Assignee: nobody → bhearsum
Priority: -- → P3
Whiteboard: [release][automation]
I'm tossing this back because I don't have time to drive it forward, I merely filed the bug after some IRC discussion.
Assignee: bhearsum → nobody
Ok. This is depends on a policy decision by drivers: do we leave the updates paths for
* 2.0.0.old -> 2.0.0.20 (and on upwards)
* 3.0.old   -> 3.0.19   (and on upwards)
in place on the update server, and therefore
* provide an update path for people who haven't used their browser in a long time * but have lots of users seemingly downloading updates only to have them fail to apply, and download again

Or do we remove or modify those update paths, and therefore not need 2.0.0.20 or 3.0.19 files on the mirrors. Over to Asa.
I've turned off Check Now for Fx 3.5.19, 3.6.17, 4.0, 4.0.1, 5.0b7 (including Firefox-Mobile-5.0b7) and Sunbird 1.0b1, since they've all been off the mirrors for some time and uptake dropped to < 500 in most cases.
Product: mozilla.org → Release Engineering
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.