Bugzilla needs to be upgraded to 5.0.6 @Gonzo Do you have cycles for this upgrade/deployment? I've created an Upgrades section in our documentation, to document the exact and complete steps involved in an upgrade here: https://wiki.freebsd.org/Bugzilla/BugzillaSetup#Upgrades It would be good for us to increase our bus-factor on deployments, taking pressure of you and hopefully increasing our development/improvement cadence too, and having said documentation is key to having that confidence For the next deploy/upgrade we can have someone else take care of it under someones (your?) supervision, and then alone going forward. I might be a good candidate for that upgrade.
Should we upgrade devel/bugzilla50 port first?
(In reply to Li-Wen Hsu from comment #1) That would, of course, be helpful :)
bz-ports (current maintainer), currently points (on freefall:/etcv/aliases) to: bz-ports: skv, tota, ohauer Which appears stale (?) We could in the short term get this changed to bugmeister@, with a long term target of not requiring us to be maintainers (the bugzilla ports should not be special) I've CC'd existing recipients of bz-ports@ on this issue. @BZ-ports Does the bz-ports recipients list need to be updated? Should this continue to remain a group/team maintainer for these ports? We'd like to change the maintainer of these ports to bugmeister in the short term, is that OK? Alternatively, we could update the bz-ports alias to include bugmeister@ such that we can update these ports. ^Triage: cc postmaster
Created attachment 215633 [details] patch This is a patch to update bugzilla50 to 5.0.6. Testbuild fine on cur-amd64.
(In reply to Kubilay Kocak from comment #0) Yes, I have some spare cycles. But this is something I wanted to discuss with bugmeister@ The way upgrade "works" right now is as follows. We have stock bugzilla50 installed on kenobi with some local modifications and whenever the port is upgraded the next clusteradm@ jail refresh brings in a new version. Since most of our modifications are plugins and reside in extensions/ directory, they are not touched by the upgrade and just dragged on from version to version. There are couple of .pl scripts in main directory, like committers sync, and on every upgrade installation script removes execute permission from them, so I have to login and fix it. We used to have couple of modifications to main Bugzilla code but they were overwritten some time ago, and since nobody complained loudly I never got around to restoring them :( The way I think it should work is we need to keep our own tree, sync with upstream on releases like I tried to do here: https://github.com/gonzoua/bugzilla/commits/freebsd (which is not hard because we make only minor changes to the upstream code) and have a bugzilla-freebsd port for it, either in main tree or in clusteradm tree. culsteradm@ poudriere would build it and deploy as a part of normal upgrade with minimum manual involvement. I never got around to actually presenting this idea to bugmeister@ and clusteradm@ If it's something we want to pursue I'll resume my efforts in that directlion.
(In reply to Kubilay Kocak from comment #3) I agree, the port is in better hands by bugmeister@. Cannot speak for the others in bz-ports but in my company we replaced bugzilla ~5 years ago with another bugtracking system, so I even don't have a test system.
^Triage: note that the blocking task is documenting exactly what is installed on the cluster, and then test by first upgrading the test instance.