Tetsuro IKEDA
te.ik****@jpta*****
2008年 2月 5日 (火) 10:41:16 JST
こんにちは。池田です。 # マルチポストになってごめんなさい(^^; 以下のソース修正版のアップロードですが、 ファイル名を変更した方が良いという声もあり、 以下のファイル名で再アップロードさせていただきました。 - MySQL-5.0.51a-tritonn.1.0.9a.src.rpm - tritonn-1.0.9a-mysql-5.0.51a.tar.gz http://sourceforge.jp/projects/tritonn/files/ 宜しくお願いいたします。 > こんにちは。いけだです。 > > senna-devとmysql MLにも入っている方が多いだろうと思ってこちらには > 投稿していなかったのですが、tritonn-1.0.9を先週末にリリースしました。 > (その後、こっちにも投げればと後悔したものの後の祭り・・・） > > http://qwik.jp/tritonn/FrontPage.html > > かずひこさんからご指摘いただいた--with-embedded-serverにてビルドエラー > になる件ですが、先ほどsrc tarballとsrc rpm(mysqlのみ)の修正版を > sourceforgeに再アップロードいたしました。 > > To:かずひこさん > メールでご提示いただいていたmysqlテストスイートのエラーの件なのですが、、 > 細かい話になるかもしれないので、senna-devではなくこちらで返答させて > いただいてもよろしいでしょうか？ > > かずひこさんWrote: > >テストといえば、make testで実行される通常のテストが、fulltext関連でfail > >になります。例えば、mysql-5.0.51-tritonn-1.0.8でmake test-forceすると、 > > > >mysql-test-run in default mode: *** Failing the test(s): blackhole > >ctype_latin1_de fulltext fulltext2 fulltext_cache fulltext_left_join > >fulltext_multi fulltext_order_by ndb_restore_different_endian_data > >query_cache rpl_trigger sp type_enum > > > >となりましたが、仕様なのか失敗なのかわかりにくく（fulltext_*はともかく、 > >blackholeとかctype_latin1_deとか）、不安になります。 > >これはどうなるのが理想的でしょうか？ > > まずこのお話を受けて、以下のドキュメントを書きました。 > > ・回帰テストの実行と判定方法 http://qwik.jp/tritonn/regression_test.html > > これを踏まえたうえで、上記のテスト結果についてですが、failすることが > 想定されているテストケースの他に、以下が失敗しているのが気になります。 > > - ndb_restore_different_endian_data > - rpl_trigger > - type_enum > > configureオプションが違うと結果も変わることがあるので一概に「まずい」とは > 言えないのですが、（個人的に）見慣れない失敗ケースなので気になります。 > > よろしければビルド＆テスト環境のシステム情報と、エラー時のログを > みせていただけませんでしょうか？ > > また、 > > >* 元のMySQLとの違いがわかるのでt/もr/もこのままでいい > >* テストが通るようにt/はそのままでr/だけ書き換える > >* fulltextインデックスをすべてusing no sennaに書き換えて、テストがとおる > >ようにする > > mysqlテストスイートについての取り扱いですが、以前一度、上記2つ目の > 「r/書き換え案」を採用しようとした時もあったのですが、MySQLのエンジニアに > 「既存のテストケースはいじらないで想定通り失敗することを確認し、正常系は > 別途テストスイートを作って確認したほうがいいよ」とアドバイスされ、 > それ以来、上記1つ目のやり方にしています。 > （その結果、sennaテストスイートとmecabテストスイートを作ったという感じです） > > ですのでmysqlテストスイートの確認ポイントとしては、必要十分なテストケースが > 成功／失敗するのを確認することと、失敗したものについては予期せぬ失敗ではない > （sig11で死んだわけではない）ことを確認すること、としています。 > > さて、話は変わりますが、同様にかずひこさんからご指摘いただいた > リリースの予告についてです。 > > 現在、Tritonnでは以下の手順でリリース作業を行っています。 > > 1. リリース対象のrevisionを決める > 2. そのrevisionを使ってsource tarball配布版を作る > 3. source tarball配布版を使って、手元でビルド＆テストを実行 > 4. binary tarball版を作る、再確認テスト > 5. binary/src rpm版を作る、軽いテスト > 6. sourceforgeへアップロード＆告知 > > このステップ2から6までは1日程度で行っているので予告期間としては > 短いかなと思いますので、ステップ１に入った時点でこのMLに予告を > だすようにしたいと思います。この場合、リリースの数日前には予告 > できると思いますが、テストで不具合が見つかった場合にソースの修正 > などが行われる場合もあります。。 > > と、、ながながと書いてしまいましたが、ご意見等いただければさいわいです。 > > よろしくおねがいいたします。 > > _______________________________________________ > Tritonn-dev mailing list > Trito****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/tritonn-dev ------------------------------ Tetsuro IKEDA Sumisho Computer Systems, Corp. http://www.scs.co.jp/mysql/ ------------------------------
