![]() Thanks to upstream help in #bugzilla on Mozilla IRC I finally found out that Perl’s use base instead of use parent was the culprit.Īfter creating symlinks to /extensions/WeeklyReport/ to avoid 404 errors for the “Weekly Bug Summary” link in the sidebar (our setup is slightly busted) and after fixing two problems with our cronjobs for whining and data collection we agreed on a date to copy the database, do some maintenance work and switch the DNS entry. Instead, I ran into problems with our custom “See Also” field changes: Adding and removing such URLs triggered errors and URLs themselves were not displayed (but their corresponding “Remove” checkbox). I was happy to see that I had been wrong: there were no problems with our custom CSS theming anymore. Wikimedia’s custom CSS was not offered as an option in the browser, nor could I log into the new Bugzilla (to check which theme is set as default in the admin settings) as the database dump we used for testing predated the creation of my user account.Īfter Sean Pringle of Technical Operations deployed a more recent Bugzilla database dump I expected further problems due to upstream changes to CSS loading. Furthermore I ran into another runtime error to fix.Īfter fixing all issues and having Bugzilla accessible via a web browser, only Bugzilla’s upstream CSS was displayed instead of our custom CSS. While doing this we also removed Bugzilla’s Sitemap extension as it created sporadic Search::Sitemap errors when running Bugzilla’s (plus it’s unmaintained anyway). Daniel Zahn installed the needed packages by adding them to puppet code. For every “missing module” error we ran into we avoided installing anything from Perl’s CPAN in Bugzilla’s /lib folder and ensured we just relied on distribution packages for a much cleaner install. ![]() During this process Daniel Zahn turned the old setup on kaulen, which was largely manual and had organically grown over the years into a proper Puppet module. While you’d normally prefer to do only one thing at a time, Daniel Zahn (of Technical Operations) and I decided to create a fresh Bugzilla 4.4 instance from scratch on the new server to see into which problems we would run. In theory.Īfter testing these CSS changes on a Wikimedia Labs instance and merging them into our 4.2 production instance, I created numerous patches and put them into Gerrit (Wikimedia’s code review tool) by diffing upstream 4.2 code, upstream 4.4 code and our custom code.Īt the same time, Wikimedia’s Technical Operations team wanted to move the Bugzilla server from the kaulen server in our old Tampa datacenter to the zirconium server in our new Ashburn (Eqiad) datacenter. Less noise and less diffing required for future upgrades. It turned out that 16 out of 22 files could be removed since there was no sufficient difference to upstream’s default CSS code (Bugzilla falls back to loading the default CSS file from /skins/default if no custom CSS file is found in /skins/custom). In late November of 2013 I started cleaning up Wikimedia Bugzilla’s custom CSS which was copied about five years ago and not kept in sync. Some reasons for upgrading can be found in this Bugzilla comment. ![]() Among many other tasks, I spent the last few months preparing the upgrade of Wikimedia’s Bugzilla instance from 4.2 to 4.4. Though we currently also evaluate Wikimedia’s project management tools, we will have to stick with our current infrastructure for a while. This post explains the technical details and challenges. Furthermore, proper configuration management for this software was set up. The software behind Wikimedia’s website for tracking software issues and feature requests was recently updated to a newer version and moved onto a new machine in a different datacenter. The original publication of this blog post can be found here. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |