Qt のモジュールの成熟レベル

この記事は Qt Blog の "Qt Modules’ Maturity Level” を翻訳したものです。
執筆: Thiago Macieira 2011年5月3日

Qt にバグを報告したことのある方であれば、すぐに対応されるものもあればそうでないものもあることに疑問に思ったことがあるかもしれません。しかし、そのほとんどが人間的な要因だということは驚くには値しないかもしれません。その報告が問題となるコードに精通している人の目に留まった場合、当然時間があればですが、優先度が P3 のように低いものであってもすぐに対応されることでしょう。逆にあまり知られていない分野のものであった場合には、修正されるまでには時間がかかるでしょう。また、[qt QHttp] や [qt Qt3Support] のように既に非推奨なものに関しては、バグが修正されることはないでしょう。

これを頭に入れた上で、モジュール化 を行うにあたり、私たち自身が Qt のそれぞれのモジュールのコードについてどのくらい精通しているかを見てみることにしました。この確認を通して Qt にある機能のうちみなさんにこれ以上使ってもらいたくないもの、協力が必要な場所、コードに満足している箇所を明らかにしたいと思います。

そして私たちは各モジュールの状態のまとめの一覧を作成しました。この一覧を モジュールの成熟 (Maturity)レベル と呼ぶことにし、オープンガバナンス化の一部として将来的に使おうと思っています。

レベルの定義

上から下まで5つの異なるレベルに加え、補助的なステージを1つ用意しました。アクティブなものから順に並べたものが以下になります。

Active(アクティブ)

• モジュールや機能は積極的に開発されており、変化も速いです
• 新機能も期待できます
• バグへの素早い応答時間
• メンテナは新しいコードやバグの修正を積極的に受け入れます

Maintained(メンテナンス)

• P0、P1、P2 のバグは修正されるでしょう
• 機能については Done(完了: 以下を参照)と同様です
• 機能は追加されるかもしれません
• メンテナは新しいコードやバグの修正を受け入れます

Done(完了)

• 安定性の確保がメンテナの一番の目標です
• メンテナはコードが「動くこと」(コンパイル、テストにパスすることなど)を保証しなければなりません
• 新機能の追加やパフォーマンスの改善は行われないでしょう
• P0 と P1 のバグは修正されるでしょう
• P0 と P1 のバグに関連しない貢献はメンテナによって受け入れられることがあるかもしれません

Deprecated(非推奨)

• 現在のメンテナによって非推奨とされたものです
• 全ての新しいコードや(P0 を除く)バグの修正はわずかな特例以外は修正されません
• コードはコンパイル可能で、最低限の機能は動作するようにメンテナンスの努力をします
• モジュールやコードは(Qt のソース、バイナリコンパチビリティの指針に従いますが)最終的には削除されます

Removed(削除済み)

• モジュールや機能が非推奨以下の状態になります
• コードのスコープが関係なしと判断されるか、別のより良い機能が Qt で提供されています
• この状態のモジュールやコードは Qt に復帰することはできません

New Maintainer Required(新しいメンテナが必要)(補助)

• これは主に「Done(完了)」の状態のコードに対するもので、コードは必要で Qt の中に残すべきなのですが、メンテナがいない状態を表します。この状態がコードに対して適用された場合、Qt コミュニティは積極的にステップアップしてこのコードのメンテナンスの責任を負ってもらえる貢献者を捜し、促します。もしメンテナがいない場合、状況に依ってはそのコードは Deprecated(非推奨) か Removed(削除済み) の状態に移行するかもしれません。

レベルによる影響とオープンガバナンス

あるコードの成熟レベルには、実際のコード自体とその作業をしているコミュニティの成果が反映されていることを理解してください。この2つの組み合わせがモジュールの成熟レベルを左右します。これは一方では特定のモジュールやサブシステム、機能、OS 対応のレベルを上げたり下げたりするために、コミュニティ自身を組織できることを意味します。あるグループがそのコードは機能的に完了していて、これ以上の努力はすべきではないという結論を意識的に下すこともありえます。そして、才能のある新しい人物のプロジェクトへの加入などで、この状況は変わっていくでしょう。一度「Done(完了)」となったコードに対して、コミュニティが開発を進める決定を下す日が来るかもしれません。

一方、これを実現するには制限もあります。コードの背景次第で拡張性がない場合もあります。例えば、Qt3Support モジュールへの新機能の追加は意味がありません。このモジュールはただ１つの目的のために存在します、それは Qt 3 アプリケーションの移植を手助けすることです。Qt 3 自体がこれ以上の新機能を持たないため、このモジュールも同様に新機能を持ちません。同時に、既存のコードは安定性が要求され、これはコミュニティによって変更されうるものではありません。新機能の追加やパフォーマンスの改善は可能でしょうが、品質は保たれる必要があります。

これは各モジュールのメンテナーを全て擬人化したときの説明です。最終決断をするのは一人です。この人は、品質、安定性、機能、要求などの全ての責任を持ち、コミュニティのその他の開発者は全てこの人をサポートすべきでしょう。この責任の元、ある貢献が受け入れられるかどうかの最終決定が行なわれることになります。メンテナは貢献の目的とコード全体の成熟度を比較し、目標の達成のためかどうかを判断します。

貢献者がサブシステムのレベルをよりアクティブになるように変えたい場合、その人は関連するコードの該当するセクションの新しいメンテナになることが可能です。メンテナになるということは、そのコードの開発を進める権利と責任を持つと言うことです。新たな投稿を承認し、新たな目標を設定し、そして要求される(これまでと同様の)品質の確保と保証を行わなくてはなりません。また、オープンガバナンスの精神の元に、メンテナにはどんな出自や背景があってもなることができます。どの会社で働いているかは問題になりません。重要なのはその人物が正しく仕事できるだけの能力を持ち、それを充分に知らしめていることです(その人の雇い主が活動をサポートする必要があるかもしれませんが、それはまた別のお話)。

次のステップ

これらのレベルは バグトラッカー や ドキュメント に記載されるべき内容です。開発者は素早くその状況を見つけられるべきで、特に使用している API が推奨されていない場合にはなおさらです。それらの注意書きをサポートするために JIRA とドキュメントはすぐに変更されるでしょう。

このリストの作成に加えて、現在の Qt のコードに対してレベルの初期の割り当てを行いました。それらは Nokia の Qt チームとその現在の開発状況を元にしたものです。割り当ての結果は後ほど公開します。