As an early testing release, we don’t yet have a detailed set of changes and release notes. Look for those as we progress toward beta. Thanks for testing!
Update: We added an important note to the upgrade documentation recommending that RT 5 be installed fresh rather than using the typical upgrade step on RT 4.x to avoid issues with older files that have been moved. Thanks to the early testers who stumbled on this issue.
Hi Jim, Rafael, could you show us screenshots, please! Our RT team doesn’t have time to install it in the next few days, but we are very interested in the new version!
We’ve started to have a play with it on a test server.
First thing we found was that the make upgrade-database needs a lot of disc space available if you have a big database with lots of large attachments in it. We chewed through more than 27GB before it fell over through lack of disc space. The culprit was the 4.5.1->4.5.2 step that does an ALTER TABLE `Attachments` CONVERT TO CHARACTER SET utf8mb4;. Folk need to make sure that they’ve either reduced the size of their attachments table using the shredder before doing the upgrade or have a large amount of free disc space available for the process to work (on the same disc that your MySQL/MariaDB database is held in).
Next up I tried to implement the README.MariaDB instructions on our CentOS7 test machine (which has MariaDB 10.4.11). It didn’t like the option in [client-server] (said it was an unknown variable) and I ended up using bastardised version of the README.MySQL instructions using the MariaDB specific sections in the /etc/my.cnf.d/* files that Redhat/CentOS provides. Seems to work OK after that:
MariaDB [rt4]> SHOW VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%';
+--------------------------+--------------------+
| Variable_name | Value |
+--------------------------+--------------------+
| character_set_client | utf8mb4 |
| character_set_connection | utf8mb4 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8mb4 |
| character_set_server | utf8mb4 |
| character_set_system | utf8 |
| collation_connection | utf8mb4_general_ci |
| collation_database | utf8_general_ci |
| collation_server | utf8mb4_general_ci |
+--------------------------+--------------------+
10 rows in set (0.001 sec)
We’ve got loads more testing to do, mostly to see what of our many local extensions and tweaks will need adjusting for RT 5.0.0. One thing we’ve noticed for example is that our “quick ticket” button arrays will need some CSS style tweaking as they’ve gone from horizontally space in RT 4.4.x to a single vertical column in RT5.0.0alpha1. Not a biggie but its that sort of stuff we’re hoping to catch.
The UI seems to be nice and clean and may help us ditch some of our local hacks (which is nice). Well done Best Practical folk - looking very promising.
OK, just one hint, or better a wish.
can you add a search box for Customfields at the admin part? Searching for CF.id and/or name would be great and then, on the Applies to part, another search box for queues etc would also be fine, as we have several thousand queues and clicking all the time trough all this is no fun,
Same on the Queue Config -> Customfields, also a search box would be very useful…
Was the extra space needed around 2x the size of the current attachments table? We have seen this with upgrades in the past and with setting up full-text indexing. MySQL appears to make a fully copy in the process of applying some kinds of changes. We often plan for 3x disk space, at least for the period while running the upgrade. Depending on the changes, the configured temp directory can also need extra space. Once the upgrade is complete, much of that space can be removed as it isn’t needed for normal operation.
We didn’t check the sizes but that sounds reasonable, as we had to remove all the attachments over 10MB in size before the make upgrade-database would work OK. Whilst it was running we did see it consume many gigabytes of storage still, but they were returned as free space as soon as the upgrade had completed.
Another little issue we’ve spotted may be a problem charting dates that we’ve submitted as a proper RT5 bug.
Does changing the Attachments table to utf8mb4 mean that MariaDB/MySQL will be able to do FullText searches without the AttachmentsIndex table? Does it mean it will be on by default?
The main issue the utf8mb4 change fixes for MySQL/MariaDB is inserting 4-byte characters in the database. While this includes characters in some languages, the primary use case we heard from users was some emojis would cause errors with the previous utf8 configuration. Now you can use all the emojis you want.
Using the database full text search still requires the extra table. We create a separate table because the fulltext indexes supported by the DB work on textual data. The RT attachments table can have content that isn’t textual, so we create a separate table with just textual data that will benefit from the index.
We manage the translations on the Canonical launchpad site here: RT: Request Tracker in Launchpad. Version 5.0 isn’t listed there yet, but we’ll add it when it gets closer to release. Changes to the 4.4 series get pulled forward if you want to make updates there.
If you want to work specifically on new translations that apply only to 5.0, I would suggest waiting for at least beta since things can still change, including text, labels, titles, etc.
