Archive.mozilla.org

Created Thursday 24/05/2007

Edited 2007-05-25 13:33 UTC

1. http://archive.mozilla.org compound downloads

1.1 Abstract

Provide month-, week-, or 10-days worth archives of nightly builds for each platform.

1.2 Rationale

1.2.1 For the users

Although one usually only needs specific builds when searching for a regression range, the builds tend to pile up.
Even though not every week's consecutive builds will be downloaded soon, you may need several consecutive builds in the end of a search.

1.2.2 For the server

http://archive.mozilla.org is slow, especially when getting a list of directories with the builds themselves.
It would be easier to make torrents or jigdo for popular build archives, unlike one for each of the thousands of the files.
OTOH, because the people who would download the archives mostly wouldn't delete them soon, the load on the server may actually become lower.

1.2.3 For the users

When downloading a nightly build of Firefox, you get an archive with only an ambiguous version number on it, and a "firefox" directory inside. To find the exact build id (YYYYMMDDHH), you have to go into the Talkback extension directory, or install Nightly Tester Tools (well, maybe not applicable in this case). Then you probably will rename the directory into something containing the buildid and marking it with the branch version or trunk, and maybe the locale and the platform.

1.3 What

1. Provide downloads of nightly builds for
- specific platform
- specific branch
- specific build range
as single files
2. Make the build directories at the client's drive reflect branch, buildid, (less important) platform, locale.

1.4 Ways to go

1.4.1 The hard way, requiring changes at the server

Have the individual build archives contain the informative directories already.
Then generate the cumulative archives by just [unpacking and] packing certain builds together.

1.4.2 An easier way, preferably server-side

Write a script that would unpack the archives, rename the directory, and pack them together.

1.4.3 A simple way for everybody, requiring more resources in the world, but less on the server

Just pack the builds together and make an installer that would unpack and rename them at the receiver's place. Also see the client proposal.

1.5 Month vs week vs 10 days

1.5.1 Month

Pros: 300Mb when separate archives packed; probably much less when unpacked builds compressed together. Easier for torrents. Easy to specify the archive date with YYYYMM (please, no YYMM).
Cons: Would take lots of space when unpacked. That can be fixed by only unpacking what is needed (see the client proposal).

1.5.2 Week

Pros: Small archive size.
Cons: Lots of archives, lots of torrents. Only 7 times better than now. A week is an arbitrary time unit chosen by humans for humans, and the only relationship of it to builds can be that the number of checkins cycles through the weeks -- no relationship to the dates.

1.5.3 10 days

Pros: Small archive size, but a bit larger than weekly ones. The archive date may be specified with YYYYMMD
Cons: Only a little better than Week.

2. http://archive.mozilla.org client

2.1 Rationale

Make regression range search faster.

2.2 Possible Features

1. Calculate the best existing median build between two specified buildids.
2. Help keep track of the regression range
3. Download the chosen build, if it's not on the drive; unpack it if it isn't yet
4. Download a cumulative archive of builds, if requested
5. Download a build in a different language/platform, if requested (optionally reset the setting back then)
6. Ability to keep the archives and the unpacked builds in different places
7. Refresh the build lists by request from the command-line, to be able to do that from cron and alike.

2.3 Unlinked references

There is a proprietary off-line Bugzilla client.

Seamonkey trunk contains some QA stuff.

Comments and suggestions welcome.