私は、wiki (MediaWiki) を使用して、開発プロジェクトのすべてのプロジェクト情報を一元化するというアイデアを試しました。これは、SVN ( SVNKitを使用) から情報を引き出す拡張機能を使用し、Bugzilla にリンクして、開発者に割り当てられた作業またはリリースに残っている作業を抽出することによって行われました。

例:

要約を返します

戻るだろう

これは役に立つと思いますか？もしそうなら、他にどのような統合が価値があると思いますか?

Bugzillaでテンプレートを適用して、ユーザーがバグの説明を入力できるようにする方法はありますか？

実際、バグの説明フィールドにいくつかのマークアップテキストを入れて、カスタムフィールドの作成を避けたいと思います。

バージョン3.2rc1をインストールしました。

私たちは MS Sharepoint を持っています -- これは、タスク リストを管理するのに悪いことばかりではありません。データは公開されており、変更や割り当てが通知されます。

Bugzilla は、管理とレポートの目的で少し簡単かもしれないと思います。優れたオープン ソース スクラム管理ツールがいくつかありますが、私は自分の政治資本の多くを使い果たしたので、今あるもの以上のものを求めることはできません。目的はお金ではなく、明らかに、私のチームには特殊なツールが多すぎるという考えです。

Bugzilla は、バグ修正以外の、より一般的なプロジェクト管理ツールとして機能しますか?

ひどくがっかりして、何か他のものをダウンロードして、より優れたプロジェクト管理ツールを求めていたらよかったのにと思いますか?

Status フィールドの動作を変更したくありません。古いシステムで使用されている状態にラベルを変更したいだけです。(古いシステムはスプレッドシートと紙で構成されています:P
私たちは 3.0 を使用しています

私たちは、Subversion over HTTPS、Bugzilla、および Mediawiki を使用して開発を管理しています。一部の開発者は Trac への移行に関心を示しているため、移行にかかるコストを評価する必要があります。

wiki と bugzilla の両方について、既存のデータを Trac に移行するか、Trac と統合する方法が必要です。Wiki ページを作成したり、バグをログに記録したりするために 2 つのアプリを使用することは受け入れられません。また、現在、これらの各アプリケーションには個別のサインオンが必要であるため、これらの各アカウントを Trac にマップする必要があります。

これらのシステムを Trac にインポートまたは統合する簡単な方法や、そのためのチュートリアルを知っていますか?

Bugzillaを新しくインストールするために、バグ番号を1以外のものから始めたいと思います。これを行う方法はありますか？

タイトルが示すように、私は現在 1 つのプロジェクトを開始しており、プロジェクトのインフラストラクチャ (SVN、電子メール、バグ追跡、オンライン フォーラムなど) をレイアウトしようとしています。

では、Bugzilla か Mantis か。

bugzilla (perl ベース) システムには、http サーバー環境変数を使用して自動的にログインする機能があります。正しい ID またはユーザー名を入力すると、自動的にログインされます。

私のサーバーは Joomla (PHP ベース) を実行しており、ログインしているユーザーに関するすべての情報を保持しています。サブフレーム内で bugzilla を実行しています。

では、PHP スクリプトからこの環境値を設定するにはどうすればよいでしょうか?

別の言い方をすれば、次のスクリプトは、PHP からのセッションの別の場所で、自分が設定した変数をどのように返すのでしょうか。

私たちの開発プロセスは、多数の bash および php スクリプト (subversion フック スクリプトを含む) によって高度に自動化されています。これらのスクリプトは、Bugzilla 3.0 インストールと統合するために多くのことを行います。

しかし、現在の統合アプローチは、バグジラ データベースを直接更新する一連の SQL 呼び出しです。これには明らかに多くの欠点があります。たとえば、データベース スキーマが変更された場合に 3.2 にアップグレードすることに神経質になります。

たとえば、バグにコメントを追加するために、longdescs テーブルに INSERT を実行しています。

だから私の（少し長ったらしい）質問は：

• Bugzilla WebServices を使用する必要がありますか (使用している場合、Bugzilla API ドキュメント以外に、すぐに慣れていない優れたドキュメントはありますか)
• または、他の Bugzilla API (直接 perl 呼び出し?) を使用する必要がありますか? また、これに関する適切なドキュメントはありますか?
• または、データベースはそれほど変化せず、「仕事をする」ので、自分がしていること（直接SQL呼び出し）を続ける必要があります

バグ追跡を非常に古いバージョンのトラックから Bugzilla に移行中ですが、Advil が不足しています。

長い間使用されてきたレガシー アプリケーションがあります。私たちのバージョン管理が数回の反復を経て、実際に多くの異なるバージョンを生成したという事実を混ぜてください。さらに悪いことに、契約上の制限により、クライアントを常に最新かつ最高の状態にアップグレードできるとは限らないため、クライアントが現在持っているバージョンで分岐、修正、テスト、およびリリースを行い、さらに別のバージョン番号を取得する必要があります。

その結果、バージョン コンボ ボックスはばかげたほど長くなります。最後に、さまざまな理由から、バグが見つかったバージョン (バージョン)、バグを修正する予定のバージョン (マイルストーン)、最終的にバグが修正されたバージョンの 3 つの異なるバージョン情報を追跡したいと考えています。 （提案を受け付けています）。これが実際に私の問題です...これは実際には、これらの顧客の一部に対して遡及修正を行った複数の番号である可能性があります（これは非常に頻繁に発生します）。

これは私があなたの集合的な知恵を必要とするところです:

Bugzilla でこれらのバージョン (見つかったバージョン、計画されたバージョン、複数の修正済みバージョン) をどのように追跡していますか?

バージョンのリンクとバグ追跡に関するベスト プラクティスは何ですか?

回答

バージョンごとにバグのクローンを作成することは追跡するのに適しているようです。したがって、ターゲット バージョンは常にマイルストーンと修正済みバージョンで追跡され、バグのあるバージョンは常にネイティブ バージョンです。

また、各クローンが元のバグをブロックするようにすることで、履歴を元の提出までさかのぼることができます。

回答を受け入れましたが、引き続きご意見をお待ちしております。