iusrepo / mariadb103

A very fast and robust SQL database server
BSD 3-Clause "New" or "Revised" License
3 stars 5 forks source link

Updated to 10.3.18 #2

Closed RahulRavishankar closed 5 years ago

RahulRavishankar commented 5 years ago

With the minor adjustments I commented on, your changes look good overall. Unfortunately the build doesn't pass.

https://cirrus-ci.com/task/4885201999626240

Patch13 doesn't apply cleanly. How do you feel about rebasing the patch on the 10.3.18 code base? If you haven't done that before I can make that change and push it to your pull request branch to be included with this change before merging.

Can you help me out with rebasing Patch 13? Can you share a few links to help me get started? I'm a newbie!

carlwgeorge commented 5 years ago

Rebasing patches is one of the trickier tasks with packaging, especially with something as large as MariaDB. Unfortunately that makes this a terrible task for a newbie. I'm not aware of specific guidelines or walkthroughs for rebasing patches in the context of RPM packaging. These links may be a good starting point for patches in general.

Fedora is going to have to rebase the patch as well to update to 10.3.18, so I did the work for that and sent them a pull request. Spoiler alert, the patch file I rebased for Fedora is here and we can reuse it in this pull request. Here are the basic steps I took.

  1. I opened the existing patch and saw that it was created with the git format-patch command. You can tell that because of the email header and the lines that start with diff --git. The patch file also has a note about an upstream commit it was based on. That upstream commit isn't in a branch, but by looking at the file changes and using git blame, I found that it was in the 10.5 branch with a different hash. It was likely rebased on the tip of 10.5 when it was merged, which changed the parent and thus change the commit reference.

  2. I cloned the MariaDB/server repo, checked out the mariadb-10.3.18 tag, created a local branch from that, and cherry picked the previous commit on top of it. It applied cleanly, but if it hadn't I would have had to resolve any merge conflicts.

  3. I created a new patch file with the command git format-patch -1 HEAD, and then added the extra notes that the existing patch file had to the top of it.

I went ahead and amended your commit to include the rebased patch. Thanks for taking a stab at this, I hope this explanation is helpful.

carlwgeorge commented 5 years ago

mariadb103-10.3.18-1.el7.ius has been published to the testing repo.