Re: MariaDB 10.3.39
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
Reply to: