Merge lp://staging/~gary/launchpad/bug632218 into lp://staging/launchpad/db-devel
| Status: | Merged |
|---|---|
| Merged at revision: | 9759 |
| Proposed branch: | lp://staging/~gary/launchpad/bug632218 |
| Merge into: | lp://staging/launchpad/db-devel |
| Diff against target: |
41 lines (+7/-1) 2 files modified
Makefile (+5/-1) setup.py (+2/-0) |
| To merge this branch: | bzr merge lp://staging/~gary/launchpad/bug632218 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Leonard Richardson (community) | Approve | ||
| Gary Poster (community) | release-critical | Abstain | |
| Graham Binns (community) | release-critical | Approve | |
|
Review via email:
|
|||
Description of the change
This is a release-critical branch to fix a critical bug.
The symptoms are described in the bug report.
LOSAs are hopefully going to verify the fix in production in a few hours. Meanwhile, I plan to go ahead and try to get this merged, because I believe it will work.
To fix this problem, I took the approach of adding an explicit step for compiling the templates within make compile. The cheapest yet most comprehensive way I could think of to do this was to process Launchpad's zcml. This should load all of our normal templates in the future. For now, it loads the Python file that registers the ++profile++ adapter and thus processes the template. You could argue that this is a side effect, and it is, but a defensible one: if zcml registers a view, the view should be instantiated with its template in order to be registered. If we ever want to allow for lazy template generation for some reason, we can deal with that then, and I don't see a big advantage for us anyway.
This also makes "make clean" clean up .pt.py files generated by chameleon.
| Graham Binns (gmb) | # |
| Leonard Richardson (leonardr) | # |
| Graham Binns (gmb) wrote | # |
I can't figure out how to get rid of the extra release-critical. :-(