[openpne-dev:554] 【提案】OpenPNE3 の BTS と SCM を Trac + SVN から Redmine + Git に変更する ([Suggestion] Switch the BTS and the SCM that are used for OpenPNE3, from Trac + SVN to Redmine + Git)

62 views
Skip to first unread message

Kousuke Ebihara

unread,
Sep 13, 2009, 11:37:58 AM9/13/09
to openp...@ml.pne.jp
(For non-Japanese speaker: (日本語話者以外の方へ) This post is a
very important suggestion about developing OpenPNE3. So I prepared the
English version text after the Japanese version that for you.)

OpenPNE 開発チームの海老原です。

OpenPNE3 の最初のコミットから 1 年が経過しました(http://
trac.openpne.jp/changeset/7708)。
この間、 プラグイン機構の追加や国際化対応、外部連携の強化な
どがおこなわれたり、ドキュメントが英語と日本語の両方用意されるよう
になったり、それぞれのプラグインに先導する開発者が就くようになるな
ど、これまでの OpenPNE とは違った、 OpenPNE3 独自の文
化というべきものが生まれつつあるように思います。

しかしながら OpenPNE の BTS (バグ管理システム)であ
る Trac (http://trac.openpne.jp/) も、 SCM (ソースコード管理システ
ム) である Subversion (https://trac.openpne.jp/
svn/) も、 OpenPNE3 の実情にはあっていません。
そこで、 OpenPNE3 に相応しい BTS と SCM の組み合
わせを検討したところ、 Redmine と Git がいいのではない
か、という考えに至ったので、その提案をしていきます。
なにか意見などあればぜひいただきたいです。よろしくお願いします。


1. なぜ BTS と SCM を変更する必要があるのか
===========================================

現状の BTS である http://trac.openpne.jp/ は以下のよう
な問題を抱えています。
a. 多くの情報が OpenPNE2 向けのものであり、その大半が
OpenPNE3 に適合していない
b. 情報が OpenPNE2 向けなのか OpenPNE3 向けなのかが
判別できない
c. ドキュメントが多くなりすぎて管理できておらず、現状に追いつい
ていない誤った情報であることが多い
d. チケットのキーワードに「確認中」「テスト待ち」などのステータ
スを設定し、進捗を把握しているが、独自の方法であり、外から見て状況
を把握できなかったり、新規参加者が適切に使用できるようになるまで時
間を要する
e. 複数のバージョンにまたがるチケットは、まず、現安定版の対応
バージョンをマイルストンに設定し、その後、旧安定版、開発版の順で
キーワードに対応バージョンを指定している。独自のレポートを用いてな
んとか管理しているが、ルールが複雑でわかりにくい
f. e のような管理をおこなっている関係で、開発の進捗がロードマッ
プから追えない(ロードマップに記録されるチケットはマイルストンにそ
のバージョンが指定されている物に限られるため)
g. チケットやレポートなどが全プロジェクトで共用である。そのた
め、ドキュメントやプラグインに関するタスクが OpenPNE3 本体の
ものと混在してしまい、扱いにくい
h. 標準で Subversion 以外の SCM を扱えず、それ以外
の SCM で開発されているプラグインなどの管理がおこなえない
i. リモートのリポジトリの管理ができず、 GitHub など外部の
リポジトリで開発されているプラグインなどの管理ができない

また、現状の SCM である https://trac.openpne.jp/svn/
は以下のような問題を抱えています。
A. 気軽に fork ができず、 fork 先での改善を fork
元にインポートするのは困難である
B. プラグイン開発などの途中で OpenPNE3 本体に問題を見つけ
た場合、コミット権限がなければ容易にフィードバックができない
C. すべてのコミットは公開されることを前提にしなければならない。
たとえば実験的なコードの中に暫定的に生のパスワードを入れる必要が
あった場合、その実験段階のコードはコミットできないまま大きく膨れあ
がっていくという危険な状態になる
D. コミットの際に、元のコードの作者と取り込んだ作業者との区別が
付けられず、すべて作業者の名前でコミットされてしまう
E. インターネットにつながっていなければコミットがおこなえない
F. リポジトリのサーバがダウンしていた場合にコミットがおこなえな

どの点も、 OpenPNE3 開発にあたっては看過できません。プラグイ
ン開発の促進や、 OpenPNE の進化の妨げになるこれらの問題は一
刻も早く解消するべきです。

BTS や SCM を変更する理由は、これらの問題を解決するためで
す。各ツールの機能によって解決をおこなうのはもちろんですが、 BTS
の場合はツールを変更すること自体に以下のメリットがあります。
(つまり、 a, b, c の問題を解決できます)
- OpenPNE2 向けの情報と OpenPNE3 向けの情報が切り離せる
- ドキュメント類の刷新をおこなうことで公開されていない情報や古い
情報などの見直しにつながる


2. なぜ採用する BTS として Redmine を選択したのか
=================================================

Redmine を採用することで、 1. にあげた以下の問題点がすぐに解
決できます。

d(独自にチケットのステータスを作成できる)、g(プロジェクト
がウェブから複数作成でき、それぞれにチケットやレポートを作ることが
できるほか、チケットを他プロジェクトのチケットと関連づけることもで
きる)、h(SVN, CVS, Git, Mercurial, Bazaar, Darcs な
どをサポートしている)、i(リモートのリポジトリを扱える)

e と f については機能では解決できませんが、現状の運用を、
「開発版で対処してからバックポート用のチケットで取り込み作業をおこ
なう」という形に変更することで対応しようと思っています。以下のペー
ジにフローを載せているのでご覧ください。
http://op3.ebihara.redmine.dazai.pne.jp/projects/openpne/wiki/Ticket_Workflow_(ja)

Trac を意識して作られただけあって、 Redmine の機能に不足はな
いと思われます。

3. なぜ採用する SCM として Git を選択したのか
=============================================

Git によって A ~ F のすべての問題を解決することができ
ます。

もちろん他の分散型の SCM でもほとんどの問題を同様に解決でき
るのですが、 GitHub によって誰でも気軽に開発できる環境があ
る、というのは Git を採用する上での大きなポイントになると思
います。

また、他の分散型 SCM に比べて Subversion との連携や移
行などが非常によくできているのも重要です。

Git の機能に不足はほとんどなく、課題となるのは Subversion で
管理されている外部のプロジェクトのソースコードをどうやってインポー
トするか(つまり svn:externals の代替手段をどうするか)、の
一点のみです。最悪の場合 OpenPNE3 のソースコードの一部として
含めなければなりませんが、致命的な問題ではありません。


4. 移行スケジュール
===================

以下のようなスケジュールで移行を進めることを考えています。

- 2009/09/14 ~ 2009/09/19 : 準備期間
- 移行にあたっての課題の洗い出しや解決をおこない、移行に向けて
の準備を進める
- 本提案についての意見を募り、問題があれば見直しをおこなう
- 2009/09/20 ~ 2009/09/21 : 移行作業
- 準備期間中にあがった課題などの解決がすべておこなわれている場
合、移行作業を実施する
- これ以降、開発チームの作業はほとんど Redmine と Git
上でおこなうようにする
- 2009/09/21 ~ 2009/09/30 : Git と Subversion の併
用期間
- この期間中Git リポジトリの更新を Subversion でも
追えるようにする
- Trac に存在する OpenPNE3 についてのドキュメントは残し
ておく
- 2009/10/01 : Redmine + Git への完全移行
- Git リポジトリの同期と Subversion の同期をやめる
- 2009/12/31 : OpenPNE3 に関する Trac や Subversion
のデータを削除
- OpenPNE3 に関する Subversion のリポジトリを削除
- Trac に存在する OpenPNE3 のドキュメントを削除

以上、よろしくお願いします。

English version (I'm sorry for that is very unreadable):

Hi,

It is a year has passed since the first time committing of OpenPNE3 (http://trac.openpne.jp/changeset/7708
) .

We added support for i18n, plugin system, and connecting with outside
service. We wrote documents both English version and Japanese version.
Individual plugin has a lead developer... OpenPNE3 has fostered an own
culture that is different from OpenPNE2 and OpenPNE1.

However, Trac that is used as BTS, and Subversion that is used as SCM,
doesn't fit OpenPNE3. So I considered a combination of BTS and SCM
that is fit for OpenPNE, I think that Redmine + Git is a very good,
and I'll suggest to use that.

1. Why does OpenPNE3 need to switch BTS and SCM?
================================================

http://trac.openpne.jp/ (now BTS for OpenPNE) has the following
problems:
a. Most of informations is for OpenPNE2, they don't fit OpenPNE3
generally.
b. It is difficult to distinguish an information that is for
OpenPNE2 or for OpenPNE3.
c. The documents are not managed because it's too much. So they
can't follow current status and many of them has mistakes.
d. We use "Checking", "Testing" and more, as keyword of ticket. We
can know a progress in the ticket but any other one doesn't know that,
and new-comer can't handle use this soon, because that rule is a
special.
e. In a ticket that is for multiple versions, its milestone is a
version of next stable. And its keyword is a version of old stable and
a version of unstable. Such a ticket is managed by original report
well. But that is a very complex rule.
f. Developing progress cannot be checking by roadmap because of e.
(Because roadmap only collects tickets that have a version of roadmap
as milestone.)
g. Tickets and reports are shared with all projects. So a task for
document or plugin are mixed with for OpenPNE3. It is not useful.
h. Doesn't have support for SCM excluding Subversion, so it can't
manage plugins that are developing under other SCM.
i. Doesn't have support for manaing remote repository, so it can't
manage plugins that are developing under remote repository (e.g.
GitHub).

https://trac.openpne.jp/svn/ (now SCM for OpenPNE) has the following
problems:
A. Contributor can't fork with a light heart. And it's difficult
importing enhancements that are in the forked project.
B. It is difficult giving a change for fixing a problem of OpenPNE
that was found when one develops a plugin. Excluding he has a
privilege for committing.
C. All of the committing must be publishable. For example, if an
experimental code needs to have a raw password temporally, that code
continues growing fat without being able to be committed. This is a
danger status.
D. In committing, an original author and a worker are
indistinguishable. A worker regarded as its author.
E. We cannot commit if we isn't in the Internet.
F. We cannot commit if the server for the repository is down.

Any points must not be overlooked in developing OpenPNE3. These
problems must be solved because they block development of OpenPNE3 and
quickening of developing plugin.

Reason of changing BTS and SCM is for solving these problems. Of
course, they are solved by features of a tool. In addition, changing
BTS has the following an advantage:
(They are solved a, b, and c problem)
- Divided informations between for OpenPNE2 and for OpenPNE3.
- Completing reform documents are reviewing a non-published
information and an old information.


2. Why do I select Redmine as new BTS?
======================================

If we use Redmine, the following problems are solved soon:

d(Can create an original status.)、g(Can create
multiple projects on the Web, every projects have own tickets and
reorts, and a ticket can be related another ticket in an another
project), h(SVN, CVS, Git, Mercurial, Bazaar, Darcs are
supported)、i(Can handle remote repository)

e and f are not solved by features. I think that it'll be solved by
backport ticket. If you want to get information for backport ticket,
please visit the following page:
http://op3.ebihara.redmine.dazai.pne.jp/projects/openpne/wiki/Ticket_Workflow

Redmine has features enough because it is created by considering Trac.


3. Why do I select Git as new SCM?
==================================

Git can solve A to F problems.

Of course, other distributed SCM will able to solve these problems
too. But Git has an advantage; there is GitHub that is a environment
of developing for everyone.

And also, connecting with and migrating from Subversion in Git works
fine than other SCMs. It is a very important point.

Git has features enough excluding it doesn't support for migrating
from "svn:externals". If worst comes to worst, OpenPNE3 contains these
externals codes. But I think that is not important.


4. Schedule for switching
=========================

- 2009/09/14 - 2009/09/19 : Preparing
- We clarify the problems and solve it, and prepare to migrate
- Exchanging opinion with community
- 2009/09/20 - 2009/09/21 : Migrating
- If all of problems are solved, we begin to migrate
- After that, development team works on Redmine and Git
- 2009/09/21 - 2009/09/30 : Using Both of Git and Subversion
- Subverion repository follows changes of Git repository
- Documents about OpenPNE3 that are in our Trac, are available yet
- 2009/10/01 : Migrating Completely
- Subversion repository doesn't follow Git anymore
- 2009/12/31 : Deleting data about OpenPNE3 that are in Trac and
Subversion
- Delete OpenPNE3 Subversion repository
- Documents about OpenPNE3 that are in our Trac, are deleted

--
海老原昂輔 (Kousuke Ebihara)
ebi...@tejimaya.com
http://sns.openpne.jp/?a=page_f_home&target_c_member_id=807
OpenPNEプロジェクト http://www.openpne.jp
株式会社手嶋屋 http://tejimaya.com

Reply all
Reply to author
Forward
0 new messages