From: Dave Miller Date: Mon, 11 Sep 2023 10:06:19 +0000 (-0400) Subject: Update release blockers (#99) X-Git-Url: http://git.ipfire.org/gitweb/gitweb.cgi?a=commitdiff_plain;h=b11c293d66ee780070e71963dfc4129137a3949e;p=thirdparty%2Fbugzilla.git Update release blockers (#99) --- diff --git a/RELEASE_BLOCKERS.md b/RELEASE_BLOCKERS.md index 1e7be2521..9ec811b03 100644 --- a/RELEASE_BLOCKERS.md +++ b/RELEASE_BLOCKERS.md @@ -1,60 +1,97 @@ -This is a list of known release blockers for Bugzilla Harmony, in prority list order. +This is a list of known release blockers for Bugzilla Harmony, in prority list +order. # MySQL compatibility & checksetup -We can and should only support current and previous releases of MySQL. -People coming from MySQL 5.6 or earlier should be nudged to use utf8mb4, which allows for emojis -and some obscure languages. +We can and should only support current and previous releases of MySQL. People +coming from MySQL 5.6 or earlier should be nudged to use utf8mb4, which allows +for emojis and some obscure languages. -Currently harmony will work with MariaDB 10+ (any version), -but will not function in MySQL 8 due to the word "groups" becoming a reserved word. +Currently harmony will work with MariaDB 10+ (any version), but will not +function in MySQL 8 due to the word "groups" becoming a reserved word. -Checksetup needs to be updated help the user understand if their mysql can work. +We need to make Bugzilla work on MySQL 8+. -For MySQL 8, either: -- We commit to supporting mysql 8 -- We detect mysql 8 and direct the user to use either mysql 5.7 or mariadb - -The later option is not very pleasant. -I believe the code I wrote over a year ago could allow us to support mysql 8, and that's in [this branch](https://github.com/bugzilla/harmony/blob/dylan/mysql-8) +I believe the code I wrote over a year ago could allow us to support mysql 8, +and that's in [this +branch](https://github.com/bugzilla/harmony/blob/dylan/mysql-8) # Upgrade Path from 4.4, 5.0, 5.2, and 5.1 -Code must be added to Bugzilla::DB::Install to support upgrading existing schemas from 4.4, 5.0, and 5.2 installs. In addition, we should provide a way to migrate from the abandoned 5.1 development branch, which has some feature mis-match with harmony. +Code must be added to Bugzilla::DB::Install to support upgrading existing +schemas from 4.4, 5.0, and 5.2 installs. In addition, we should provide a way +to migrate from the abandoned 5.1 development branch, which has some feature +mis-match with harmony. Things to check: - Multiple aliases was reverted and we'll have to have code to handle that. +- 5.1 supports usernames that are distinct from email addresses. Harmony + doesn't have that yet. - (TODO, I'm sure someone will make a suggestion) # Merge or Re-Apply the Email Code from 5.0 -Bugzilla Harmony's email code is from BMO, which was 4.2. -In 5.0 or so, the email code was refactored to use a much better supported email module (Email::Sender, I think) - -We need to merge that change back in, or just write the code over again. +Harmony is a descendant of Bugzilla 4.2. The email mechanism used in 4.2 +depends on Perl modules that no longer have upstream support. BMO maintained +their own bugfixes to those modules, but that’s not something we want to do +upstream. Version 5.0 rewrote the email code to use currently-supported Perl +modules. That needs to be ported into Harmony. # Postgresql Compatibility -I think most of the postgres incompatibility is in the "BMO" extension, and in order to be able to -release I now believe we should remove the BMO extension from our codebase. -This is unfortunate because it has a lot of useful features, but given resource constraints it is the best move. +We suspect, but don’t know for certain, that BMO may have moved to using +PostgreSQL on their back end at one point, and may have switched back to MySQL +and/or Maria DB since. Bugzilla upstream supports PostgreSQL, but for whatever +reason some of BMO’s code for handling it was placed in the Bugzilla extension +they used for their local customizations instead of in the actual database +abstraction modules. This code needs to be migrated back to the database +abstraction modules so their extension can be disposed of. # Sensible, Default Logging Configuration -Bugzilla::Logging controls how the application logs. It has support for defaults, but those defautls -were written for BMO and don't make sense for the app. +Bugzilla::Logging controls how the application logs. It has support for +defaults, but those defautls were written for BMO and don't make sense for the +app. -This is left a bit vague, but here's the guiding principal: when you install bugzilla it needs to log in -a place you expect it to. +The defaults need to be updated to log to a more generic location users are +likely to have, or walk through setting it during the installation script. # Docker and Containerization -I would like the Dockerfile to be rewritten such that the ENTRYPOINT is the bugzilla.pl script, so that -the container can be used as a drop in replacement for the bugzilla.pl executable. +I would like the Dockerfile to be rewritten such that the ENTRYPOINT is the +bugzilla.pl script, so that the container can be used as a drop in replacement +for the bugzilla.pl executable. It would be good to add sub-commands for checksetup and the jobqueue to this. bugzilla.pl sub-commands can be defined in the Bugzilla::App::Cmd::* namespace. -If we release harmony and it has a good (and small!) container, it will look good. - - +If we release harmony and it has a good (and small!) container, it will look +good. + +# Documentation + +BMO gutted some of upstream's documentation about Bugzilla, so the entirety of +the documentation for the Harmony branch will need to be reviewed and +potentially heavily edited prior to release. We may need to port some of the +existing upstream documentation back into it. + +# Release Notes + +Release notes for Harmony will be a HUGE task. Since Harmony diverged from +upstream at 4.2, but backported many (but not all) upstream features, someone +will need to go through and determine what changes the two forks did NOT have +in common so we can properly document in the release notes any features that +were dropped or new features being picked up when compared to version 5.2. + +- Start with an empty list. +- Go through [Harmony's commit + logs](https://github.com/bugzilla/harmony/commits/main) going all the way + back to Version 4.2, and make note of anything new/changed that's release-note + worthy. +- Go through [5.2's commit + logs](https://github.com/bugzilla/bugzilla/commits/5.2) goinng all the way + back to Version 4.2 + - anything new/changed that is already on the list needs to be removed from + the list (because 5.2 already had it, so it's not a change) + - anything new/changed that is NOT already on your list needs to be added to + the list as a removed feature