Closed Bug 305642 Opened 19 years ago Closed 19 years ago

verify that binary patching for updates works as expected

Categories

(Toolkit :: Application Update, defect)

1.8.0 Branch
x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: chase, Assigned: chase)

Details

(Keywords: fixed1.8)

Ensure that binary patching for updates work as expected.  This is a
verification that the client can handle binary diffs.

Our options to accomplish this are:

  1. Test by hand
     a. Define a URL test-URL that references an update XML file.
     b. Have test team update to latest build.
     c. Have test team change app.update.url to test-URL.
     d. Respin build systems. 
     e. Create binary diff by hand from earlier build to now latest build.
     f. Upload binary diff to web and update XML file referenced by test-URL
        to list the binary diff and complete update.
     g. Check test team updates to see if the binary diff was applied.

  2. Test automatically
     a. Create a system which generates binary diffs automatically from 
        available complete updates.
     b. Make AUS2 capable of issuing binary updates.
     c. Hook new build system functionality into AUS2.
     d. Check test team updates to see if the binary diff is applied.

We plan to do two but we aren't there yet.  One is our stop-gap with impending
beta release.

How do we verify which update of partial/complete is downloaded?  Is this data
written to a log file?

Filing per cbeard's request in Deer Park weekly meeting.
blocking1.8b4+ per Deer Park meeting
Flags: blocking1.8b4+
Writing a script to make binary patch MAR files which are not quite correct
(they don't cumulatively remove old files) is very easy. I can do that which
would make basic testing a lot easier.
(In reply to comment #2)
> Writing a script to make binary patch MAR files which are not quite correct
> (they don't cumulatively remove old files) is very easy. I can do that which
> would make basic testing a lot easier.

Offline, mentioned mozilla/tools/update-packaging/make_incremental_update.sh. 
This is the script 2a would use to generate the binary patch from two complete
updates.  However, 2a isn't complete at that point.  Here's 2a with greater
resolution:

  1. Designate a system 'diff-system' which will publish binary patches.
  2. Create a script that listens on diff-system for new builds.
  3. When it finds a new update it executes:
     a. Download the old and new complete MAR files.
     b. Create a new binary patch using make_incremental_update.sh.
     c. Publish the binary patch to the FTP farm.
     d. Create AUS2 update metadata for this partial patch.  This metadata is 
        read from the update metadata for the complete patch.
     e. Publish the info to AUS2.
Also if the build/packaging side of the automatic binary patch system fell into
my lap and worked to satisfaction, I would gratefully accept that help.
Flags: blocking1.8b5+
I'll hold the token for now.  ETA is 1 week.
Assignee: nobody → chase
(In reply to comment #0)
>   2. Test automatically
>      a. Create a system which generates binary diffs automatically from 
>         available complete updates.
>      b. Make AUS2 capable of issuing binary updates.
>      c. Hook new build system functionality into AUS2.
>      d. Check test team updates to see if the binary diff is applied.

This has been implemented and is now live.  Resolving fixed.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Flags: blocking1.8b5+
Keywords: fixed1.8
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.