(In reply to Mitchell Hentges [:mhentges] from comment #2)
As discussed with Aki on IRC, it sounds like there's some options for solving this in the longer term:
- In the
update-verify task, don't raise an error if the difference is just in comments.
- Note: what about changes in the middle of multiline comments? Do we parse JS files?
- Note: what about changes in comments in a multitude of different file types? Do we add parsing support for each one?
Turns out we already support making transformations to cope with channel-prefs.js differences, see compare-directories.py. We can likely extend this to squash the new differences, and get back to green update-verify jobs.
- When the update pack was created, the patch for
channel-prefs.js wasn't included. Why was that? Include that "patch-filtering logic" into
channel-prefs.js is the main place that sets what update channel any given install is on, and there are a couple of reasons that we don't modify it when applying an update. The main one is that the file will have different content for different releases, and we publish release RC builds on the beta channel. A user who installs beta has
pref("app.update.channel", "beta"); in channel-prefs.js, while a regular/end-user would have
pref("app.update.channel", "release");. We don't want to move beta users to release when we give them the release RC build  . So we use a special update instruction,
add-if-not, which will add channel-prefs.js in the (unexpected) case of it being missing, but otherwise respect what is there already. This also helps for QA testing because they can modify the channel easily, and it won't be reset if multi-update scenarios from older releases.
 Why do we do that ? We want to make sure no issues have snuck into the RC since the last beta, and because we used to have a problem where any given compilation could tickle a bug in some BIOS code, and we didn't know until we shipped it to users.