バグ報告・翻訳・パッケージング・コード修正・広報活動などなど―OSS に貢献してみるには？

2016/07/30バグ報告・翻訳・パッケージング・コード修正・広報活動などなど―OSS に貢献してみるには？

1/43

バグ報告・翻訳・パッケージング・コード修正・広報活動などなど― OSS に貢献してみるには？

武山文信日本 openSUSE ユーザ会


2/43

みなさん

って何かご存知ですか？


3/43

正しいのはどれ？

● 1. サーバールームでモフモフできるカメレオン型ガジェット

● 2. Ruby で簡単に Web アプリを作れるフレームワーク

● 3. 今年で20周年のドイツ生まれの Linux ディストリビューション


4/43

正解

● 3. 今年で20周年のドイツ生まれの Linux ディストリビューション– S.u.S.E Linux 4.2 で独自のディストリビューションになってから

● Q: RedHat 系ですか？ Debian 系ですか？A: どちらでもありません！

● Q: OpenSUSE ですか？openSUSE ですか？A: o は小文字です。IPhone ではなく、iPhone なのと同じです


5/43

デスクトップはこんな感じ


6/43

YaST でかんたん設定


7/43

さて本題


8/43

● どのようなことに関わっていますか？興味がありますか？– コーディング– パッケージング– バグ報告– 翻訳– ドキュメンテーション– 動作検証– コミュニティ運営・広報


9/43

始める前に…

● 何をするにも、関わろうとしている OSS のコミュニティに入っておくとよい– 例: メーリングリスト– 日本語のサブコミュニティがある場合も


10/43

バグを見つけたときにどうするか？


11/43

バグ報告

● まずは開発コミュニティにバグの存在を伝える● バグの報告から解決までを管理するツール

– Bugzilla, GitHub Issue, Mantis, …– どのプロジェクトでも、何かを使っているはず


12/43

修正に繋がるバグ報告をするには？


13/43

修正に繋がるバグ報告の心得

● 必用な情報を提供する– 今日はここを中心に話します

● 継続的に連絡を取れるようにする– 開発者がバグを再現できない

● 情報不足● 機材・環境がない→報告者がデバッグに協力する必要あり

– 不具合が修正できたかの最終確認● 最初の報告以降、連絡が取れなくなる人多し


14/43

事例 1/2

● 例「ibus-mozc を使っていると、GNOME のロック画面で日本語入力が有効になる」

● 起こりうる反応– ちょっとユーザビリティが悪くなるね– 日本語にしか影響が無いのか…限定的だから後回しでいいな


15/43

事例 2/2

● 別の表現「IBus の一部の CJK 向け変換エンジンが有効のとき、GNOME のロック画面で変換が有効になり、パスワードが見えてしまう」

● 反応– 「これ、セキュリティインシデントだろ」– 「CVE に報告だ」– 「日中韓の３ヶ国語で影響が出るのか」

ちょっと大げさになりすぎた感もある


16/43

最悪の結果を伝える

● 起きうる最悪の（十分に悪い）現象を伝えると対応してもらいやすい– データ消失やセキュリティ– その他、どのような場合でも


17/43

余計な情報を付けすぎない

● 悪い例（架空）:Firefox と Chrome と Eclipse が起動しているときに、Firefox が定期的にクラッシュする– 何のバグ？

● 実際:ライブラリの問題で色々なアプリケーションでクラッシュが発生していた


18/43

必要十分な情報を付けるには

● 条件を外しても不具合が再現するかを確認し、余計な条件を外す– 例: Chrome が起動していなくても再現しないか？

● そのアプリケーションでしか起きないのか、不具合の出るアプリケーションの一例なのかをはっきりさせる– 投稿前に、他のアプリケーション– Firefox は不具合のでるアプリケーションの一例ならば、

一例と明示する


19/43

開発者にバグ報告を読んでもらう

● バグの原因のある部分の開発者に読んでもらわないと修正してもらえない– 担当者を割り当てるのはバグスクリーニングチームの仕事– 報告内容が不適切であれば、正しい人に割り当てられない！

● 読んでもらうべき人物がわかっている場合は連絡しておく– バグレポートの CC に入れておく、メールするなど


20/43

コミュニティでも相談

● バグ報告したことを、メーリングリストなどで共有しておくとよい– 他の人が再現するか試してくれる– 不十分な内容を補完してくれる– 担当者を知っている人がいれば、連絡してくれる

● 日本語のコミュニティを活用して英語でのコミュニケーションが成り立たないときに助けてもらう（よくある）


21/43

自分でコードを修正して取り込んでもらう


22/43

レポートよりもパッチ

● コードを読んで不具合の原因が分かってしまうこともある● どんなバグレポートよりも、パッチがあると修正が速い

– パッチ = diff -u で編集前後の差分を取ったもの

--- scribus-1.4.4.mod/scribus/pageitem_textframe.cpp 2014-12-06 02:13:59.599941139 +0900+++ scribus-1.4.4.mod/scribus/pageitem_textframe.cpp.mod 2014-12-08 22:56:23.540099486 +0900@@ -822,6 +822,7 @@ unsigned int code = ch.unicode(); if ( (0x2E80 < code && code < 0x2EFF) || // CJK Radicals Supplement (0x3000 < code && code < 0x303F) || // CJK Symbols and Punctuation+ (0x3040 < code && code <= 0x30FF) || // Hiragana, Katakana (0x31C0 < code && code < 0x31EF) || // CJK Strokes (0x3200 < code && code < 0x32FF) || // Enclosed CJK Letters and Months (0x3300 < code && code < 0x33FF) || // CJK Compatibility


23/43

パッチの送り方

● パッチの送り方は OSS プロジェクトにより様々– GitHub で Pull request を送る– Git を通してレビューシステム (Gerrit, Review Board) に送る

● LibreOffice, KDE, ...– バグ管理システムにパッチを添付する

● Free Desktop 管轄のものなど、色々– メーリングリストに添付して送る

● Linux kernel● 大きなプロジェクトなら、どこかに送り方が書いてあります

– 小さなプロジェクトであれば、たいてい GitHub?


24/43

気軽に投稿していいのか？

● 大きな管理されたプロジェクトでは「作法」に従うことが重要– Linux kernel とか– そのプロジェクトのコミュニティで作法を確認したほうがよい

● ほとんどのプロジェクトでは、コードでの貢献は特に歓迎される


25/43

Linux ディストリビューションのパッケージング


26/43

パッケージング

● アプリケーションやライブラリをビルドして、zypper/yum/apt でインストールできるようにすること

● ソースコードからのビルド方法がわかれば、単純作業が多い– でも人が足りない

● 実際にしていること– ソースコードからビルドするスクリプト、パッケージの依存関係、説

明などの情報を作成（Spec ファイルなど）– ソースコードをダウンロードしてきて、一部のファイルを修正– ビルド・アップロード


27/43

openSUSE のパッケージングに参加するには？

● 誰でもパッケージの branch & submit request が可能

M17N

branch

MozcMozilla Editors

submit

openSUSE Factory → Tumbleweed

openQA による自動テスト

アップデート

レビュー


28/43

パッケージのアップデートは難しくない

● ファイルを差し替えるだけの単純作業が多い

$ osc branch -c M17N mozc

$ wget http://xxxxxxx.com/mozc-2.1.yyy.xxx.tar.xz

- Version: 2.0.yyy.xxx+ Version: 2.1.yyy.xxx

$ emacs mozc.spec

$ osc build

パッケージを branch して手元にコピー

新しいバージョンの tar を入手

spec ファイルのバージョン番号書き換え

ビルド！（仮想ビルド環境を自動構築）


29/43

レビューが通ればおしまい

● コマンドだけではなくブラウザからも操作可能

accepted


30/43

続き

● ビルド後、インストール＆テストし...

-------------------------------------------------------------------Mon Feb 9 15:11:04 UTC 2015 - [email protected]

- Upstream update to 2.x.xxx.xxx + hoge hoge

$ osc vc

変更ログを入力（ほぼ定型文）

$ osc sr

branch 元に提出！

$ osc commit

OBS のバージョン管理にコミット


31/43

OSS の翻訳活動


32/43

2つの翻訳

● アプリの翻訳（今日のメイン）– メニューの File という文字列をファイルに翻訳– 英語力はほとんど不要であるが、アプリケーションの知識が必用

● ドキュメントの翻訳– ヘルプやオンラインのドキュメントの翻訳– 長文の英語読む英語力と、自然な日本語に直す日本語力が必用


33/43

翻訳の方法

● 翻訳前後の文字列を含んだファイルを編集することが多い– PO 形式など– テキストエディタ、専用ツール、Web ベースのツールで翻訳

msgid "File"msgstr "ファイル"

msgid "Edit"msgstr "編集"


34/43

専用ツール (Lokalize)

翻訳前の文字列

翻訳後の文字列


35/43

Webベースのツール（Transifex）

翻訳前の文字列

翻訳後の文字列

Git などの開発ツールが使えなくても、翻訳に参加できる


36/43

OSS の広報活動


37/43

OSC に出展する

● すでに出展している OSS のコミュニティであれば出展のお手伝いを募集している…と思います– openSUSE ユーザ会は毎回、出展側のお手伝いを募集しています

● 使っている OSS で OSC に出展したい– → OSC 事務局へ

● OSC のスタッフとして、OSS コミュニティ全体と関わるのもあり


38/43

各コミュニティのイベントに参加する

● openSUSE mini Summit– openSUSE ユーザーが集まる年に１度のイベント– 他のディストリビューションや OSS も同様のイベントがある

● 気軽に発表する– 「どういうふうに使っているのか」


39/43

海外イベントも！

渡航費は8割サポート（スポンサーによる）2016の発表募集中（来週まで）


40/43

紹介記事を書く

● ブログや Qiita で● 書いたことをその OSS のコミュニティで共有すると良い

– 内容についてフィードバックをもらえる→よりよい記事になる


41/43

同人誌New!

8/14 (日) コミックマーケットC90


42/43

最後に

● 何をするにも、関わろうとしている OSS のコミュニティに入っておくとよい

● どのようにバグ報告・修正・翻訳すればよいかが分かる

● OSS に関わるきっかけを作るコミュニティ・取り組みも– Google Summer of Code

● 学生なら– OSS Gate

● 定期的に開発に参加してみるイベントを開催


43/43

最後に

● Have a lot of fun! — 楽しみましょう！– 分からないことはコミュニティに聞きましょう

● openSUSE のコミュニティは– 日本openSUSEユーザ会 http://opensuse.geeko.jp/– Twitter: @opensuseja– Facebook: http://www.facebook.com/opensuseja– openSUSEプロジェクト公式日本語メーリングリスト

● [email protected] 公式アナウンスなど● IRC

– #opensuse-ja– 毎週日曜日20時から IRC で雑談会

http://opensuse.geeko.jp/

http://www.facebook.com/opensuseja

Technology

バグ報告・翻訳・パッケージング・コード修正・広報活動などなど―OSS に貢献してみるには？