If I'm reading that correctly, the problem was that some MySQL versions couldn't actually restore database dumps they created using mysqldump if strict mode was enabled. That's a pretty ugly bug.
If you're on strict mode, TEXT and BLOB types in MySQL 5 don't support a default value. Bugzilla didn't set anything for those fields; relying on MySQL putting in the default value. At that time Bugzilla had loads of places where the database would insert things into the database. Fixing all of those would've been pretty daunting task and IMO MySQL not supporting those defaults anymore is a too invasive (backwards compatibility breaking) change. See http://dev.mysql.com/doc/refman/5.6/en/data-type-defaults.ht....
This was around the time that GNOME once again was upgrading its Bugzilla instance (IIRC), plus lots of people were moving to MySQL 4. Fixing this was pretty urgent and assumed that MySQL's behaviour would change back.
Because of this MySQL change being backwards incompatible, it also broke restoring backups. This patch wouldn't help with that though (it just changes the setting for the database connection created by Bugzilla; it doesn't change the server setting).
It took many years until the Bugzilla code was less of a mess. If the same bug would've been opened nowadays a proper fix could've been made. Back then, urgh.
> Because of this MySQL change being backwards incompatible, it also broke restoring backups.
No matter how you paint it, if MySQL isn't able to restore a backup created with the backup utility of the same version, then this is MySQL's fault.
It is absolutely not acceptable for a backup utility to run through but produce something that then cannot be restored. I would have expected mysqldump to blow up or even better, the newer daemon to not start up if it sees a schema that it doesn't support any more.
See for details https://bugzilla.mozilla.org/show_bug.cgi?id=321645#c20
PS: I wrote the patch to disable strict mode.