付録C フリーなバグ追跡システム
プロジェクトでどのバグ追跡システムを採用していても、 文句を言う開発者は必ずいます。 この傾向は他の標準的な開発ツールよりも強いようです。 私は、バグ追跡システムが使う人の目に見えることと、 ユーザーと開発者がやりとりを双方向に行うツールであることから、 (時間があれば)改善したいと思う点が想像しやすいこと、 そしてそれを口に出して説明しやすいのが理由だと思っています。 こうした不平不満は話半分に聞いておきましょう — 以下に示すバグ追跡システムの多くはとても優れたソフトウェアです。 以下の一覧では、バグ追跡システムが追跡するものとして「問題」という用語を使います。 しかし、それぞれのシステムは、 これに対応するものとして「欠陥」や「バグ」あるいは「チケット」などの独自の用語を使うこともあることに注意してください。 注意: この調査が最初に行われたのは 2005 年であり、 それ以降にもい
リリースを安定させるプロセス
リリースを安定させるプロセス とは、 リリースブランチをリリースできる状態に持っていく作業です。 つまり、どの変更をリリースに含めるか、含めないかを決定し、 その方針に従ってブランチを整備することです。 この "決定" という言葉には、厄介なことがたくさん含まれています。 リリース直前に新機能がたくさん出てくるのは、 協調的なソフトウェアプロジェクトでは日常茶飯事です。 開発者はリリースが近いことを知ると、 それに乗り遅れまいとして大急ぎで変更作業を終えようとします。 これは勿論、リリースするときにはまさに起こって欲しくないことです。 開発者は自分の好きなペースで新機能を実装していればいいのであって、 自分の変更が今回、または次のリリースに含まれるかどうかは心配しない方がいいのです。 ひとつのリリースに多くの変更を直前に詰め込もうとすればするほど、 コードは不安定になり、（普通）多くのバグ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
