On Mon, Jul 03, 2023 at 04:29:58PM +0300, Otto Kekäläinen wrote: > Hi! > > FYI, MariaDB did an extra batch of releases in June. This message is > about 10.3 series. > > No MariaDB 10.3.40 did not happen as 10.3 series it out of scope. > However, thinking of cherry-picking 10.4 changes, I did however check > the release notes of 10.4.30. The 3 top issues at > https://mariadb.com/kb/en/mariadb-10-4-30-release-notes/ I tracked > down to be commits: > > https://github.com/MariaDB/server/commit/928012a27ae2d1549f1b3e6975b9d22652bbea3a.patch > https://github.com/MariaDB/server/commit/8f3bf593d24de9cd4744e71c86de80cd502786c7.patch > https://github.com/MariaDB/server/commit/aa713f5ae20513b0c4d9a74ea3ba3ea3bbdcd719.patch > > None of the above applied cleanly on 10.3.39, so I gave up. > > The 4th issue in release notes is reverting a change that I checked > was never on 10.3 series at all, so not relevant. > > As an extra experiment I mass applied all commits from 10.4 branch on > 10.3 that applied easily in > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/38 > and pushed to CI to see how much breaks. > So, if I understand correctly, this suggests that the individual patches are somehow dependent on changes made in other commits which precede them (those additional commits not being security-specific). Is that right?
The approach of replaying all of the commits from the 10.4 branch on the 10.3 branch is interesting. > This type of backporting has never been done, so this is a bit of > experimental, but I wanted to try it out and ask thoughts about if > this makes sense from the LTS team. > The main risk that I see is the possibility of instability or a latent fault that comes from transposing an entire sequence of commits in this way. While I can see some value in this approach, I am not convinced that this approach is better than migrating to a supported minor release branch. There is clearly an up front risk in moving away from 10.3 (perhaps to 10.6 or 10.11), but that risk is quantifiable (I think). That said, even if we weren't replaying all of the commits from one branch to an older branch, but instead doing the normal backporting of specific commits that fix specific CVEs, there is still risk of regression. What I mean by all of that is that there is risk on both sides. But even if the "replay all the commits" strategy works in this instance, its long term viability isn't clear. We would potentially be in a similar situation when 10.4 is no longer supported (or prior to that point if we encounter a patch that won't support a straightforward backoport), and then we would have to decide at that point whether to try to apply the strategy using 10.5 as a source branch, or to migrate to a newer version altogether. Regards, -Roberto -- Roberto C. Sánchez
