MySQLにパッチを投げる試投編

nikezono,Fri Mar 01 2024•misc

Back

TL;DR;

kentsu-san の記事を読みましょう https://rabbitfoot141.hatenablog.com/entry/2023/12/06/170449 (opens in a new tab)

あらまし

転職を機にMySQLのコードに触れる機会が大きく増えた． MySQLは非常に歴史を感じさせるソフトウェアだ．

同じことをするコードが全く別の書き方で各所に散らばっていたりする．一言でいうとDRYではない．
コメントに古い情報が書いてあることがしばしばある．
かつては MySQL Internals というサイトがあり，開発者はここを読めば全体の設計や実装のガイドラインがある程度掴めた・・・のだと思うが，今は失伝しているため，コンポーネントの存在意義が初見でわからなかったりする．

別にこれらのことを批判するつもりはない．自分の書いたコードだってこんなのは日常茶飯事だし．むしろ，せっかくMySQLに触りながら仕事をしていく以上，問題に気づいたらcontributeしようと思いたった．

この記事は，最初のPRを投げるまでの記録．

やってみる

"MySQL Contribute" で検索して出てくる記事を参考にしよう．

日本語だとこのあたりを参考にした．

残念ながら，公式のドキュメントには少し古い運用が書いてあり，「MySQL Bugsにパッチを投稿するとマージされる」というフローを中心に扱っている．しかし現在ではGitHubからカジュアルにPRを投げることが可能で，PRからMySQL Bugsのチケットが自動生成される．

たとえば私は以下のPRを参考にした．

fix stale link about functions #508 - mysql/mysql-server (opens in a new tab) - GitHub上のPR
Contribution: fix stale link about functions (opens in a new tab) - MySQL Bugs上のチケット

自動生成されたチケットには Contribution: というprefixがつくようだ． OracleのMySQL Blogで公開された MySQL 8.1.0 is out ! Thank you for the contributions !! (opens in a new tab)という記事では，以下のようにパッチが紹介されているが，これを見ればGitHubからのContributeがかなりの割合を占めていることがわかる．遠慮なくPRを投げてもよさそうだ．

しかし，PRがマージされるためには，自分の書いたコードの著作権を譲渡することについて同意する必要がある．具体的には，OCA (opens in a new tab)に登録する．これが最大の関門だ．私の場合，はOCAをsubmitしてからレビューされるまでに1ヶ月弱かかった．Oracle側のワークフローがどうなっているかContributorには見えないので，気長に待つのがいいだろう．ちなみに，OCAを出す前に bugs.mysql.com (opens in a new tab) にアカウントを作っておくこと（もちろん，同じメールアドレスで）．そうでないと，以下のように返信が帰ってきてレビューが一時ストップする．

I am responsible for processing MySQL OCAs and I found yours. ... However one of the requirement for processing MySQL OCA is that user have to have an account in our bug system. Unfortunately I was not able to find yours, can you please be so kind and create this account?

そんなやつおらんやろ，という罠だが私は引っかかった．

実践

ということで，ためしにコメント修正の軽微なPRを投げた．これが最初のPRだ．

しかし，パッチが verified になったところでおや？と思った．ここから先の動きはどうなるのだろうか？私のパッチはいつマージされるのだろうか？いくつか似ているチケット（軽微なコメント修正）について見てみた．

どうやら，コメント修正レベルのcontributionは verified になっても mergeされないことが多そうだ．前者はいまだに修正されていなくて，後者は2021年に報告されてるけど8.2.0でようやく別のチケットとして修正されている (opens in a new tab)．

つまり， git log に名を残すことを狙ってcontributionしていくのであれば，コメント修正のような軽微なパッチを送るのは意味がないのかもしれない． Oracle側にメールでそれとなく基準を聞いてみたが，「開発チームがマージするパッチを判断する」という答えしか返ってこなかった．

追記＆修正

上記の

どうやら，コメント修正レベルのcontributionは verified になっても mergeされないことが多そうだ．つまり， git log に名を残すことを狙ってcontributionしていくのであれば，コメント修正のような軽微なパッチを送るのは意味がないのかもしれない．

これは嘘だった。以下のようにリリースノートにも名前が載ったし、github上でも確認できるcommitが生まれた。

Fixed an erroneous comment in include/my_command.h. Our thanks to Sho Nakazono for the contribution. (Bug #114507, Bug #36455468)

ただし、github上でのアカウントと紐づけられることはない。ここは少し残念・・・だけど、コメント修正程度でもコミットログに載るのはモチベーションになる。

余談: "Not a bug"

いくつか参考になりそうなPull RequestsやMySQL Bugsを漁っていると，なかなかすごいチケットを見つけた．

Bug #102668: Unused parameter documented in the comment as used (opens in a new tab)

内容としては，よくある「コメントとコードが乖離してるよ」というレポートなのだが・・・返信がすごい．

> [22 Feb 2021 13:55] MySQL Verification Team
> Hi Mr. Zhong,
>
> Thank you for your bug report.
>
> We accept the bugs in our code that cause problems in production or performance issue. We also accept bugs that improves our documentation or makes it more clear to the public.
>
> However, code comments are there for our developers only and do not affect in any possible way our users.
>
> Not a bug.
> [22 Feb 2021 14:11] MySQL Verification Team
> Hi Mr. Zhong,
> 
> We decided to accept code comment errors as bugs.
> 
> Hence, verified as reported.

この "Not a bug." というフレーズはMySQL Bugsでは頻出ワードのようで，良いバグレポを送ってもこれで一蹴されるケースがしばしばあるようだ．しかし違う担当者が「やっぱこれバグだわ」と意見を翻すこともまたよくあることのようだ．同じチームの中に仕事のスタンスが全く異なる人がいるのはすごい，ちょっと羨ましいなと思う．

MySQLにパッチを投げる 試投編