6

私たちの環境内には、コア コードベースと、そのコードベースのいくつかのクライアント固有の実装があります。クライアントが問題を提起した場合、それがクライアント固有の問題なのか、コア コードベースの問題なのかを判断する必要があります。

私たちは Bugzilla を使用してバグを追跡しています。また、コア コードベース用の Bugzilla 製品と、クライアント実装用の Bugzilla 製品があります (機能を強化するために製品をカスタマイズしているため)。クライアントがコア コードベースに関連するバグを提起した場合、コアとクライアントの 2 つの Bugzilla 製品でそのバグを提起し、両方のチームが問題を認識できるようにする必要があります。理想的には、これらのバグを関連付けて、2 度修正しようとする努力を無駄にしないようにし、2 人のプロジェクト マネージャーがその問題の進行状況を完全に把握できるようにします。

これまでのところ、バグという言葉が魔法のように指定されたバグへのリンクになり、他のバグの詳細に簡単にアクセスできるように見えるため、「バグに関連する」という作品を含むコメント/説明を使用することをお勧めします。これは、「コメントに検索が含まれる」基準を介して検索できます。

他の人はこれをどのように行いますか？

4

1 に答える 1

7

あなたのBugzillaで依存/ブロックフィールドが有効になっている場合、次のワークフローで大まかに使用します。

  • クライアント固有の製品のバグ X が報告されました。
  • コア製品に存在することが判明した場合、このバグの別の「コア」バージョン (バグ Y) がコア製品にファイルされ、クライアント固有のバグをブロックするように作成されます (Y は X をブロックし、X は依存しますY);
  • コア チームはコア バグ Y の修正に進みます。
  • コア バグが修正されると、クライアント固有のバグ X も修正されます (追加の作業が必要な場合とそうでない場合があります)。

コメントでリンクの代わりに依存/ブロックを使用する利点は次のとおりです。

  • 通知: 誰かがバグ Y を変更すると、バグ X を見ている全員にも通知が届きます。
  • 強制: Bugzilla は、少なくとも 1 つの未解決のバグに依存するバグのクローズを許可しないように調整できるため、X をクローズする前に Y をクローズする必要があります。

以前は、1 つのコア製品と 2 つの生産製品が顧客に出荷されるという、同様のセットアップがありました。ただし、すべての製品に対して 1 つのチームがあったため、よりシンプルになりました。通常、バグは製品版で報告され、その後、製品版で修正するか、コア製品にエスカレーションするか、他の製品版に重複したバグを作成しました。同じ問題に対して 2 つのバグ レコードが存在する場合は常に、依存関係 / ブロックでリンクされていました。

于 2009-09-28T13:27:40.727 に答える