~bzr-pqm/bzr/bzr.dev

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
===========================
LaunchpadでBazaarを使う
===========================


動機付け
==========

コミュニティはチームとは違う
----------------------------------

ソフトウェアの初回リリースをしなければならない人々のチームというのは、\
一人から数千人まで、その規模は多岐に渡ります。
その要求に応じて、技術的な課題、経営上の課題、その両方が非常に大きなもの\
になる可能性があります。
Bazaarユーザガイドで説明したように、"ふさわしい"プロセスを選択し、\
それに見合ったワークフローをサポートするBazaarのようなツールを使うことは、\
大きな手助けになるでしょう。

しかし、ソフトウェアによる成功のためには、すばらしいチーム以上のものが\
必要です。 - それは、健全で活発な *コミュニティ* です。
このグループは、通常はチームよりもはるかに大きく、なぜならそのソフトウェアに\
関心のあるすべての人 - 開発チーム、ユーザ、トレーニングパートナー、\
サポートパートナー、サードパーティの開発者など - を含むからです。

すばらしいコミュニティというものはフリー(自由)ソフトウェア
コミュニティでは良く理解されています。
しかし、その適用はオープンソースの世界を越えて広がっています。
もっとも成功している商業ソフトウェアのベンダーは、
そのフラッグシッププロダクトと共に成長するコミュニティ\
を作り上げ、運営することがたくみなのです。

すばらしいチームと同じように、すばらしいコミュニティも偶然できるものではありません。
良いポリシーとガイドラインが、参加者同士の健全なコミュニケーションと正しい振る舞い\
を育てるために不可欠です。
この話題についてもっと深く知りたければ、Karl Fogelのすばらしい著書 - \
`Producing Open Source Software <http://www.producingoss.com/>`_ - を見てください。


協調開発に必要なもの
---------------------------------------------------

コミュニティの情報とワークフローを追跡し、管理するためには、賢いツールセットが重要です。
そのようなツールを、協調開発環境(Collaborative Development Environments : CDEs)と呼びます。
一般的には、WEBベースでアナウンスや案件、バグを管理します。
`Launchpad <https://launchpad.net>`_ 、
`SourceForge <http://sourceforge.net>`_ 、
`java.net <http://java.net>`_ 、
`SAP Community Network <https://www.sdn.sap.com/irj/sdn>`_ などに、CDEsの例があります。

関係するコミュニティとの協調を助ける
-------------------------------------------------

多くの成功しているプロダクトは、その下流にそれを使うたくさんのプロダクトがあります。
言いかえると、他のコミュニティとやりとりをして、自分の変更が彼らにどんな影響を与えるかを\
理解することで、新しい挑戦が成功するのです。
これは、以下のようなプロダクトでは特に明白です。:

* プログラム言語、たとえばPyhon、PHP、Ruby、Java、Perlなど
* コンパイラ、たとえばgcc、JDKなど
* ライブラリ、たとえばzlib、opensslなど
* フレームワーク、たとえばZope、Ruby on Rails、Springなど

.. XXX downstream dependenciesは、直訳だとわかりづらい気がするのでやや意訳
   In other wordからの一文の訳がよくわからない

.. Many successful products have a huge number of downstream dependencies.
   In other words, a new challenge arises with success: dealing with other
   communities and understanding how your changes will impact them. This is
   most obvious for projects like:

しかし、アドオン機能を持つメジャーなアプリケーション、たとえばFirefox、Thundervird、\
OpenOffice.org、Drupal、Wordpress、Joomlaなどにも、このことはあてはまります。

コミュニティの境界をこえて案件や障害修正の追跡と管理をするための作業をサポートして\
くれるツールが必要です。
そのようなツールは、両極端にいるどちらのユーザも助けてくれます。:

* 自分のことばで問題を報告することができるユーザ。
  たとえば、「オペレーションシステムX上のアプリケーションYで、Zタイプのイメージの\
  レンダリングがおかしい」など

* 変更や障害修正が下流のプロダクトに与える影響をよりよく評価できる開発者。
  たとえば、「グラフィックライブラリのバグを修正することにより、これらの10個のOS上の\
  5つのアプリケーションに恩恵がある」など

その間にいる人々は、 *点線をつなぎ* 、上流と下流との間のコミュニケーションを担うという\
重要な役割を果たします。
多くの場合、彼らはエンドユーザのためにバグを修正したり、パッチをリリースしたり、上流の\
開発チームに修正内容を提示したりします。
それらすべてを持続可能な方法で常に追跡しつづけることは、簡単なことではありません。

Launchpad: 開発をもっと効果的に、摩擦は少なく
-------------------------------------------------

Canonical は、 `Ubuntu <http://www.ubuntu.com>`_ や `Bazaar <http://bazaar.canonical.com>`_
の開発に出資しているのと同じように、
オープンソースコミュニティ向けの無料のサービスとして
Launchpad <https:launchpad.net> も提供しています。
Launchpadは、以下の注目すべき理由から、もっともエキサイティングな
CDEsのひとつです。

* トラッキング対象のたくさんのもの同士の関係を具体化しています。
  たとえば、ソースコードのブランチをバグ修正に関連づけることができます。

* これまでの資産を管理するのと同じように、ロードマップ、マイルストーン、ブループリントの\
  機能によってこれからの開発の計画や追跡もできます。

* 翻訳ツールやパッケージングサービスを提供することで、翻訳者やテスターがコミュニティに参加し、\
  貢献するときの抵抗を少なくしています。

* 違うコミュニティ同士が、関連する案件やロードマップに対してともに作業するための結びつきを\
  提供します。

言いかえると、Launchpadは、あなたのコミュニティの成長を助け、 *コミュニティ内* と\
*コミュニティ間* との両方でワークフローの摩擦を減らすようにデザインされています。
究極的には、機械的なタスクにつかう時間をなくし、興味ぶかい開発により多くの時間を\
さけるようにすることを意味しています。

Bazaar: Launchpadのバージョン管理クライアント
---------------------------------------------

このチュートリアルは、BazaarとLaunchpadがどのようにして一緒に使うことができ、\
どれだけお互いを引き立てあうのかを考えます。
以下のことは覚えておいてください。:

1. BazaarはLaunchpadなしで使うこともできます。
2. LaunchpadはBazaarなしで使うこともできます。

それでも、別々に使うよりも一緒に使った方がより大きな力を発揮するように設計されています。


Launchpadでのブランチの検索、閲覧
===================================

利用できるブランチの検索
--------------------------

分散型バージョン管理を導入することには多くの利点がありますが、できなくなってしまうこと\
のひとつとして、利用できるすべてのブランチについて知っている中央サーバがないという点が\
あります。
実際、分散環境では、関連するブランチは、インターネット中の文字どおり100もの場所に存在する\
可能性があります。(もしくは、イントラネットの中でも同様です。)

Launchpadは、ブランチのデータベースを提供することによって、このギャップをなくします。

ブランチの登録
--------------------

ブランチはLaunchPadにアップロードすることもできますし、別の場所にあるブランチを単に登録する\
こともできます。
また、ブランチには *New(新規)* 、 *Development(開発バージョン)* 、 *Mature(安定)* 、 *Abandoned(破棄)*
というステータスを付加することができます。

Note: 外部のブランチは、CVSやSubversionのような従来のバージョン管理ツールでホストされて\
いても構いません。
これらのシステム上のコードは定期的にスキャンされ、Bazaarのブランチに変換されます。
もちろん、最大限の正確さを求めるのであれば、外部のブランチをBazaarでホストすることが望ましいです。

ブランチの閲覧
-----------------

ブランチは、名前、登録者、作者、ステータス、世代、最終コミット時刻などの多くの属性によって\
リストアップやフィルタリング、並べ替えができます。
また、ブランチを閲覧することによって、以下のようなことが簡単に分かります。:

* ブランチがどこからダウンロードできるか
* 変更をアップロードする方法
* それぞれで行った最近のコミットと変更内容
* 指定したバージョンの個々のファイルのソースコード


Launchpad上のコードへのBazaarでのアクセス
=========================================

プロジェクトのコードの取得
----------------------------

Launchpad 上には多数のプロジェクトがあり、その最新のコードがBazaarで
管理されていても、CVSやSubversionで管理されていても、Bazaarを使って
以下のように簡単にコードを取得することができます。 ::

  bzr branch lp:project-name

`project-name` は、Launchpad上のプロジェクトIDです。以下にいくつか例を挙げます。::

  bzr branch lp:inkscape
  bzr branch lp:amarok
  bzr branch lp:python
  bzr branch lp:rails
  bzr branch lp:java-gnome

そのあと、好きなエディタやIDEを使って、コードを手元で参照したり、必要があれば編集したり\
することができます。

もし、プロジェクトに複数のシリーズ(例えば、開発用とメンテナンス用)が登録されている場合は、\
以下のコマンドで指定したシリーズの最新のコードを取得することができます。::

 bzr branch lp:project-name/series

変更内容の公開
-----------------------

イライラするバグを修正したり、ずっと欲しかったクールな機能を追加したりしたら、それを友達に\
アピールしたり、そのコードを他の人に公開して世の中をもっと良くするときです。
これまでに説明したとおり、LaunchpadはBazaarによる無料のコードホスティングサービスなので、自分の\
ブランチをプッシュして他の人がそこからコードにアクセスできるようにすることができます。
例えば、あなたが関連するチームのメンバーだとすると、以下のようにLaunchpadにログインします。::

  bzr launchpad-login userid

`userid` は、LaunchpadのユーザIDです。
そのあと、以下のように変更をチームのブランチにプッシュすることができます。::

  bzr push lp:~team-name/project-name/branch-name

他の人は、以下のようにそのコードをダウンロードすることができます。::

  bzr branch lp:~team-name/project-name/branch-name


自分用のブランチ
-----------------

あなたがチームのメンバーではなかったとしても、Launcpadであなたの変更内容を公開することができます。
この場合、以下のようにして単純に自分用のブランチを作成します。::

  bzr push lp:~userid/project-name/branch-name

他の人は、以下のようにそのコードをダウンロードすることができます。::

  bzr branch lp:~userid/project-name/branch-name

Note: 自分用のブランチに公開したときも、ちゃんと上流の開発者にあなたのブランチについて通知されるので、\
全てのユーザに一般的に適用できる内容で、かつプロジェクトの品質基準を満たしていれば、彼らはその変更を\
プルすることができます。

.. Package source branches

パッケージのソースブランチ
-----------------------------

`maintaining packages for Ubuntu using Bazaar` に書かれているとおり、
Launchpad から簡単にパッケージのソースブランチにアクセスできます。
現在の(デフォルトの)系列のパッケージのソースブランチは、次のようなコマンドで
ダウンロードできます。 ::

  bzr branch ubuntu:package

ここで、 *package* はアクセスしたい Ubuntu のパッケージ名です。
Ubuntu の特定の系列 (例: Maverick, Lucid) のパッケージブランチを
ダウンロードするには、次のコマンドを使います。 ::

  bzr branch ubuntu:maverick/package

Ubuntu の系列は単に最初の文字を使う形に省略することができます。
たとえば、上の例は次のようにも書けます。

  bzr branch ubuntu:m/package

いくつかの Debian の系列でも、 Launchpad からソースブランチをダウンロードする
ことができます。デフォルトの系列であれば次のようにダウンロードできます。 ::

  bzr branch debianlp:package

そして、特定の系列の場合は次のようになります。 ::

  bzr branch debianlp:lenny/package

``debianlp:`` スキーマは Launchpad にある Debian のソースブランチにしか
アクセスできないので注意してください。

.. _`maintaining packages for Ubuntu using Bazaar`: https://wiki.ubuntu.com/DistributedDevelopment


Lanchpadでのブランチの関連づけ
===============================

ブランチをバグと関連付ける
-------------------------------

ブランチを登録したあと、それにバグを関連づけることができます。
そうすることで、そのバグに関心をもつ人々がそのブランチを追いかけ、修正が公開されたらダウンロード\
することができます。

そのための手順は以下のとおりです。

1. Questionから、そのバグに移動します。

2. `Actions` から `Add branch` を選択します。

3. ブランチを選択します。

4. 必要に応じて、関連づけのステータスを設定します。
   *Fix In Progress(修正中)* がデフォルトですが、すでにブランチ内にで問題に対処しているのなら、\
   *Fix Available(修正済)* に設定することもできます。

もし望むのなら、バグとブランチとの関連づけに好きなコメントをつけることもできます。

BazaarでのコミットによるLaunchpadのステータスの変化
----------------------------------------------------------

BazzarとLaunchpadを一緒につかうことで、ステータスのメンテナンス作業をへらすことができます。
Bazaarでコミットしたときに、以下のように--fixesオプションを指定します。::

  bzr commit --fixes lp:1234 -m "..."

この1234というのはバグIDです。こうすると、バグ-ブランチ間の関連づけのステータスが *Fix Available* \
に変わります。
一回のコミットで複数の問題を修正する場合には、--fixesオプションを複数回指定できます。

この機能のすばらしい点のひとつは、コミットするときにLaunchpadにアクセスできなくてもいいということです。
``--fixes`` オプションではメタデータを保存し、次にそのブランチがLaunchpadにプッシュされたときか、\
オンラインで再スキャンされたときに、Launchpadはそのメタデータを検出します。

Note: Launchpadは、ブランチでバグが修正されたからといって勝手にバグをクローズすることはありません。
これにはいくつかの理由があります。
一つ目の理由は、ほとんどのチームでは、たいていブランチをトランク(メインの開発ブランチ)にマージしないと\
バグが修正されたとはみなさないためです。
二つ目の理由は、多くのチームでは、バグが修正されたことを確認するためには、「開発者がそう言っている」と\
いうだけではなくそれ以外のプロセスがあるためです。

あとで説明しますが、マージ管理機能が現在Launchpadで開発されており、この機能がリリースされれば、バグの\
ステータスを *Fix Committed* に自動変更する機能がもっと適切なものになります。


ブランチをブループリントと関連づける
-------------------------------------

ブランチを登録したあと、それにブループリントを関連付けることができます。
そうすることで、そのブループリントに関心を持つ人々がそのブランチを追いかけ、開発中の新機能をテストする\
ことができます。

そのための手順は以下の通りです。

1. Questionから、そのブループリントに移動します。

2. `Actions` から `Link branch` を選択します。

3. ブランチを選択します。

もし望むのなら、ブループリントとブランチとの関連づけに好きなコメントをつけることもできます。


Launchpadをつかったリリースの管理
=================================

変更内容の統合
-------------------

ブランチが開発され、公開されたら、コミュニティでは一般的に、その変更内容をコアプロダクトに統合して\
エンドユーザにリリースする前に厳格なプロセスを通します。
その中には、以下のような手順が含まれるでしょう。:

* 仲間による変更内容のレビュー

* どのリリースにその変更を含めるかの決定。たとえば、次のメンテナンスリリース、次のメジャーリリース、\
  もしくはその両方。

* 機能の回帰テストの実行

* パフォーマンスが基準を満たすかどうかを確認するためのベンチマーキング

* エンドユーザテストのための早期提供リリースの作成

* ドキュメントの更新。たとえば、そのリリースのためのリリースノートなど

* ユーザインターフェイスやドキュメントの他言語への翻訳

このセクションでは、プロダクトのコードの品質を高めるために役立つLaunchpadの機能のいくつかについて簡単に\
説明します。
Bazaarとの強力な一体化が、それをスムーズにするためのポイントです。

Note: 以下にあげる機能の中には、まだ開発中のものもあります。
もし、これらの機能に興味があるのなら、以下のリンクでLaunchpadベータテストチームへの参加を検討してください。:
https://help.launchpad.net/JoiningLaunchpadBetaTesters
そうすれば、各機能の早期提供版を手に入れて、広くリリースされる前に開発者にフィードバックを送ることができます。


ブランチのマージの提案
-----------------------

Launchpadでブランチに移動したあとに実行できるアクションのひとつに、 *Propose for merging(マージの提案)*
があります。
この機能では、どのブランチがこのコードを取り入れるべきかを指定します。

どのブランチがコードラインへのマージ提案中なのかという情報を追跡することは、リリース管理者が、\
リリース日までに何を完了させなければならないか、または何を完了させることができるかを常に把握するために役立ちます。
この情報をもとに、必要なレビューを実行してからブランチをマージすることを確実に行うことができます。
単純なケースでは、リリース管理者は手作業でブランチをマージします。
もっと高度なケースでは、ブランチがあるべきステータス(たとえば、 *Review completed(レビュー完了)*)になった\
ときにロボット(`PQM`_ のような)に自動的にマージさせることができます。

.. _PQM: https://launchpad.net/pqm


コードレビューの追跡
----------------------

コードレビューの状態や会話の内容、成果物を追跡するために、Launchpadでたくさんの機能が開発されています。
これらの機能は、ブランチのマージ提案やブランチ閲覧の機能に統合されると思われます。


パーソナルパッケージアーカイブ(PPA)
------------------------------------

PPAは、開発者や開発チームが、早期提供版でテストとフィードバックを行うユーザにカスタムビルドモジュールを渡す\
手助けをします。
言い方を変えると、PPAによって、開発者はその変更内容に関心を持つテスターのコミュニティを結成することが\
できるようになります。
テスティングコミュニティは、パッケージをインストールし、テスト期間中にそれを実行し、その後はシステムから\
きれいに削除することができます。

より詳細な情報は、 https://help.launchpad.net/PPAQuickStart を参照してください。


翻訳
------------

Launchpadの翻訳モジュールは、誰もがアプリケーションを自分が知る言語に簡単に翻訳できるように設計されています。
翻訳者は、深いレベルの詳細を知る必要はありません。

Launchpadは、プロジェクトの各メジャーバージョンに対する翻訳を別々に記録するので、だれかが新しい開発バージョンの\
作業を始めていても、安定版の翻訳の改良を続けることができます。
プロジェクトをまたがってリソースを共有することにより、翻訳のスピードを短縮しています。
75万件の翻訳済みのテキストのライブラリからの自動抽出機能と、1万9千人の翻訳者のコミュニティとが、プロジェクトを\
多くの言語に翻訳する時間を短縮してくれます。

.. XXX Translation speed in reduces by sharing resources across projects. > in は isの間違いだと思われる。

要約
=======

私たちが参加するコミュニティは、それがオフラインであれオンラインであれ、私たちがどのような種類の人間であるかを\
表すものです。
逆に言うと、あなたがコミュニティのために選ぶツール - 特に、CDEとバージョン管理ツール - は、誰がそのコミュニティ\
に参加するのかということ、また、その人たちがどれだけ簡単にコミュニティに貢献できるかということに大きな影響を与えます。

LaunchpadとBazaarは、単独でもとても役に立つツールです。
一緒に使えば、以下のことが可能になります。:

* コミュニティの、ソースコードやナレッジのような資産の追跡を助ける。
* コミュニティへの参加の妨げを軽減して、コミュニティの成長を促す。
* 関係するコミュニティとのやりとりを助ける。

具体的には、LaunchpadはあなたのBazaarブランチを管理する無料のコードホスティングサービスであり、ブランチをオンラインで\
閲覧でき、ブランチとバグやブループリントを関連づけることができ、Bazaarへのコミット時にバグについて記述することによって\
ブランチ-バグ間のステータスを自動的に変更することができます。
*すばらしいアイデア* を、 *エンドユーザの元で実行されるコード* にするまでのプロセスを合理化するための、より進んだ統合\
機能が現在開発中です。

もし、BazaarとLaunchpadがさらにどのように統合されてほしいかについて、何かフィードバックすることがあるのなら、\
Bazzarメーリングリストで私たちに連絡してください。
bazaar@lists.canonical.com.

Launchpadは自由ソフトウェアプロジェクトをサポートするための無料のサービスとしてデザインされていますが、Canonicalはこれを\
商業ソフトウェアの開発者にも、その要望次第で提供することができます。
オープンソースであってもなくても、Launchpadがあなたのコミュニティの運営に役立つと考えていただけるのならば幸いです。