To be able to reach this point I needed to port more important customizations into extensions. But before embarking on this task, I wrote a patch splitter tool.
The diff between stock Bugzilla 3.4 and GNOME one (gotten with some magic bzr invocation taken from this site) was just too large to grasp. I tried rebasing GNOME Bugzilla on top of 3.4, but I gave up after less than 2 minutes. It was a folly.
So instead, I moved the code to git, produced a git patch, annotated it and wrote a tool that split it into myriad of smaller, self-containish patches. The effect is this branch.
I did that to know exactly what changes in code each customization brought. This effort wasn't probably worth it, but at least it was a bit of fun. The tool sits here. Go there at your own risk.
Next was GnomeAttachmentStatus extension. I already wrote a post about it, so I won't be repeating myself here. I'll only add that I'm not happy with its code. Now I wonder if some of the hacks there are necessary. Probably yes, who knows?
Technically it wasn't next extension I put into customizations, but it was the second one I wrote from scratch. I needed a central place where template overrides could be stored. The necessity appeared when I was porting some other extensions. Two of them were overriding the same template. So, best idea is to take that file from those two and put it into the third, right? Right.
Also, the problem with overriding templates is that if original one changes then the override might need updating. And that doesn't happen by itself. Nor does this extension do this for us. But instead it makes the checksetup to fail if Bugzilla admin does not acknowledge the change. Or forgets to do so. Or misses to do so.
That is the third and the last extension I wrote from scratch so far. Its name is rather self-explanatory. It mostly serves as a kind of enforcing documentation. That means that checksetup will fail if any of listed extensions is either not loaded or inactive. Of course, the dependencies are provided by extensions itself. This one only provides a mechanism.
Hm, it's quite least useful of all of them out there I think.
Browse, DescribeUser, Developers, GNOME, PatchReport, ProductInterests, StockAnswers and WeeklyBugSummary extensions were already ported some years ago by Olav Vitters (as far as I know). I just had to import them into single git repository and make some minor changes. Like porting to GnomeAttachmentStatus. Moving their template overrides to TemplateOverride. Adding list of runtime dependencies for ExtensionDependencies to check. Fixing some small bugs.
TraceParser extension was slightly more work - it is targeted for 3.6. Fortunately 3.6 introduced a new extension format which hasn't changed too much since then. The only minor difficulty was that some TraceParser's table was referencing comment_id column in longdescs table. And that column has changed its width between 3.6 and 4.0 from INT3 to INT4. Or, translating from Bugzillese to mysqlese, from mediumint to integer. In the end most of the time spent on this extension was waiting. Waiting patiently for checksetup to finish its churning only to find out that either it was killed because something. Or checksetup was running on wrong test instance (without updated TraceParser extension). Third run finally confirmed that migration works.
Of course, this all sounds backwards, but my changes in logic were nonexistent, so everything should work (famous last words).
So, please don't tell him this port, ok? Thanks.
Well, that's it. There are still a lot of bugs to be fixed, I'm sure. But Bugzilla is already usable. Ever-awesome André Klapper already jumped in and fixed a bunch of them. The customizations are in bugzilla-gnome-org-customizations git repo. Many thanks to André and to Andrea Veri for overseeing and helping me with this work. And to Olav for doing most of this work for me two (or more) years ago.
Oh, and actually I am going to repeat myself - the git-bz tool will need some small update, because attachment status field name has changed.