If we backport and then run all the standard checks,  this will generate a delay in the release of a few days

I suggest including this fix in a subsequent patch release, that could be available by the end of the week or the beginning of next week.

The DM-CCB need to approve any further delays to the 17.0 or a new patch release.

Since we have no tests that exercise the code being modified (otherwise the problem would have been discovered earlier), I don't see why running "the standard checks" should be necessary.

It seems to me that a 17.0 followed immediately by a 17.0.1 that we recommend everyone use instead will create more confusion, although perhaps it's good training for the user base.

Right, the standard checks do not exercise the lsst.display.firefly module.

Operationally, the request is to apply the 17.0 tag to the 16.0-14-g377950a version of the display_firefly package, instead of the version that carries the 17.0rc2 tag. (I hope I am using "version" and "tag" correctly.)

I am reluctant to further delay this release.  We cannot fix everything in a release and there will certainly be more bug fixes to follow.  I would prefer to make this release as planned and include this (and possibly other) bug fixes in a subsequent patch release.  

Please go ahead with this release. This release is holding up a test milestone - the bug will not prevent that test happening. We certainly have problem of monolithic releases where we should be releasing some components separately  - i.e. perhaps plugins could be separately released.  We can certainly do patch or minor release during normal DMCCB work.