[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
developers/releng/pullups.xml 1.6
- Subject: developers/releng/pullups.xml 1.6
- From: kano@na.rim.or.jp (OKANO Takayoshi)
- To: www-changes-ja@jp.NetBSD.org
- Date: Sun, 5 Aug 2007 23:38:49 +0900 (JST)
- Message-Id: <200708051438.XAA30419@shell.rim.or.jp>
- In-Reply-To: <200707251559.AAA82591@shell.rim.or.jp>
- References: <200707251559.AAA82591@shell.rim.or.jp>
- Delivered-To: mailing list www-changes-ja@jp.netbsd.org
- Mailing-List: contact www-changes-ja-help@jp.netbsd.org; run by ezmlm-idx
In message <200707251559.AAA82591@shell.rim.or.jp> I wrote:
> ディレクトリー単位で全部翻訳できていたほうが都合がよいので、
> (あんまり意味はなさげですが) 以下のファイルの翻訳をやります。
developers/releng/pullups.xml 1.6 です。ツッコミをお願いします。
月曜日までに異議がなければ commit します。
訳の全文は
http://www.na.rim.or.jp/%7Ekano/tmp/developers/releng/pullups.xml
http://www.na.rim.or.jp/%7Ekano/tmp/developers/releng/pullups.html
に置いてあります。
以下は原文との差分です。
--- developers/releng/pullups.xml.orig 2007-05-29 22:29:48.000000000 +0900
+++ developers/releng/pullups.xml 2007-08-05 23:26:11.000000000 +0900
@@ -1,190 +1,186 @@
-<?xml version="1.0"?>
+<?xml version="1.0" encoding="ISO-2022-JP"?>
<!DOCTYPE webpage
PUBLIC "-//NetBSD//DTD Website-based NetBSD Extension//EN"
"http://www.NetBSD.org/XML/htdocs/lang/share/xml/website-netbsd.dtd">
-<webpage id="developers-releng-pullups">
+<webpage id="ja-developers-releng-pullups">
<config param="desc"
- value="NetBSD Release Engineering: Pull-up Requests" />
+ value="NetBSD リリースエンジニアリング: pull-up 要求" />
<config param="cvstag"
value="$NetBSD: pullups.xml,v 1.6 2006/08/08 06:04:25 riz Exp $" />
+<!-- Based on english version: -->
+<!-- NetBSD: pullups.xml,v 1.6 2006/08/08 06:04:25 riz Exp -->
<config param="rcsdate" value="$Date: 2006/08/08 06:04:25 $" />
<head>
<!-- Copyright (c) 1994-2006
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED. -->
- <title>NetBSD Release Engineering: Pull-up Requests</title>
+ <title>NetBSD リリースエンジニアリング: pull-up 要求</title>
</head>
<sect1 role="toc">
<sect2 id="list-toc">
<sect3 id="general">
- <title>General Information</title>
- <para>Release branch pull-up requests are the mechanism by
- which developers request changes to be pulled up to a
- release branch after the source tree has been branched for
- release, and by which they request that changes be pulled
- up for subsequent patch releases. These requests are sent
- to us, the release engineering team, so that the changes to
- the release branch can be carefully monitored, and quality
- can be maintained.</para>
- <para>Pull-up requests are sent to a
- branch-specific email address.</para>
+ <title>一般的な情報</title>
+ <para>リリース枝の pull-up 要求は、
+ リリース枝の分岐後に、開発者が (trunk での)
+ 変更をリリース枝に反映して、
+ この変更をその後のパッチリリースに反映するための仕組みです。
+ リリース枝への変更を注意深く観察して、品質を保てるようにするため、
+ pull-up 要求は、
+ 私たちリリースエンジニアリングチームに送ってください。</para>
+ <para>pull-up 要求は、
+ 枝ごとに専用の電子メールアドレスに送ってください。</para>
<itemizedlist>
- <listitem>NetBSD 4 pull-ups go to
+ <listitem>NetBSD 4 の pull-up は
<email>pullup-4</email>
</listitem>
- <listitem>NetBSD 3 pull-ups go to
+ <listitem>NetBSD 3 の pull-up は
<email>pullup-3</email>
</listitem>
- <listitem>NetBSD 2 pull-ups go to
+ <listitem>NetBSD 2 の pull-up は
<email>pullup-2</email>
</listitem>
- <listitem>NetBSD pkgsrc pull-ups go to
+ <listitem>NetBSD pkgsrc の pull-up は
<email>pullup-pkgsrc</email>
</listitem>
</itemizedlist>
- <para>Policy issues or general questions for the Release
- Engineering team can go to
+ <para>リリースエンジニアリングチームの方針に関する問題や、
+ 一般的な質問は、
<email>releng</email>
- .</para>
- <para>Specific release issues/concerns should go to the
- appropriate list:</para>
+ へ送ってくださって結構です。</para>
+ <para>個々のリリースに関する問題や懸念事項は、
+ 各リリース用のメーリングリストへ送ってください。</para>
<itemizedlist>
- <listitem>NetBSD 4 goes to
+ <listitem>NetBSD 4 については
<email>releng-4</email>
</listitem>
- <listitem>NetBSD 3 goes to
+ <listitem>NetBSD 3 については
<email>releng-3</email>
</listitem>
- <listitem>NetBSD 2 goes to
+ <listitem>NetBSD 2 については
<email>releng-2</email>
</listitem>
- <listitem>NetBSD pkgsrc goes to
+ <listitem>NetBSD pkgsrc については
<email>releng-pkgsrc</email>
</listitem>
</itemizedlist>
- <para>This page gives guidelines for pull-up requests.
- Explained this way, it probably seems like pull-up requests
- are a lot of work. In a sense, they are. Before you submit
- a pull-up request, you should have verified it and tested
- it, and you should have a good understanding of what is
- changing. However, that's work you've already done before
- you should even think about submitting the request. The
- only additional work is documenting that information for
- us. There's no point in making us figure all of that
- information from scratch, when you already know it and can
- easily pass it along to us.</para>
+ <para>このページでは、pull-up 要求の指針を掲載します。
+ ここの説明をご覧になると、pull-up 要求では、
+ やることがたくさんあるんだと思われることでしょう。
+ ある意味、そういうものです。
+ pull-up 要求の提出前には、検証とテストをして、
+ 何が変わるのかをよく理解しておく必要があります。
+ ただし、それは、要求の提出を考えた時点で、もう済んでいるはずです。
+ このため、さらに必要な作業は、私たち
+ (リリースエンジニアリングチーム) 向けに文書化することだけです。
+ pull-up 要求に関する全情報をあなたはすでに知っており、
+ その情報を私たちに伝えるのは簡単なのですから、
+ 私たちにゼロから全情報を作らせる必要はまったくありません。</para>
</sect3>
<sect3 id="requirements">
- <title>Pull-up Requirements</title>
+ <title>pull-up に必要なこと</title>
<itemizedlist>
- <listitem>Pull-up requests must always be sent by a
- developer who is responsible for checking if the change
- is eligible for an update release.</listitem>
- <listitem>Pull-up requests should be tested in the
- release branch
- <emphasis>before</emphasis>
- being submitted to the release engineering team. It's not
- releng's responsibility to sanity check pull-up requests
- (though sometimes we will).</listitem>
- <listitem>Pull-up requests to multiple release branches
- should be sent in separate email messages to the
- appropriate addresses.</listitem>
- <listitem>Do <emphasis role="bold">not</emphasis> use resending
- (also known as bouncing) to submit a pullup request. Either use
- forwarding or write a new e-mail.</listitem>
- <listitem>Pull-up requests should contain accepted
- solutions to the problems that they address. That is, if
- a change was just made to the current NetBSD sources, and
- is being debated, don't submit a pull-up request until
- resolution has been reached.</listitem>
- <listitem>Multiple files can be modified by a single
- request, but each request should address a single
- problem. Independent requests should be submitted in
- separate mail messages. That makes our bookkeeping job
- much easier.</listitem>
- <listitem>Pull-up requests must contain the following
- information:
+ <listitem>pull-up 要求は、かならず、
+ その変更が最新版リリースにとってふさわしいことを、
+ 責任をもって確認できる開発者が送る必要があります。</listitem>
+ <listitem>pull-up 要求は、リリースエンジニアリングチームに提出する
+ <emphasis>前に</emphasis>、
+ リリース枝でテストをおこなうようにします。
+ pull-up 要求の正常性確認は、
+ (おこなうこともあるでしょうが)
+ リリースエンジニアリングチームの仕事ではありません。</listitem>
+ <listitem>複数のリリース枝への pull-up 要求は、
+ 枝ごとに別の電子メールにして、
+ それぞれ適切なアドレス宛に送るようにします。</listitem>
+ <listitem>pullup 要求の提出に、再送信
+ (バウンスともいう) は使っては<emphasis role="bold">いけません</emphasis>。
+ 転送にするか、新規の電子メールを書くか、どちらかにします。</listitem>
+ <listitem>pull-up 要求での変更内容は、
+ 受け入れられた問題解決策とします。
+ つまり、変更内容が current NetBSD のソースの変更そのままであり、
+ かつ議論が続いているものの場合は、決着がつくまでは
+ pull-up 要求を提出してはいけません。</listitem>
+ <listitem>複数のファイルの変更を単一の要求でおこなうことができます。
+ ただし、各要求は、単一の問題に対するものとします。
+ 関連性のない要求は、別々のメールにして提出するようにします。
+ こうすることで、私たちの仕事の管理がかなり簡単になります。</listitem>
+ <listitem>pull-up 要求には、
+ 以下の情報を含める必要があります。
<itemizedlist>
- <listitem>A description of the problem fixed by the
- request (for the commit messages and, if a patch
- release is being generated, for the patch release's
- CHANGES file), including a list of any Problem Reports
- addressed by the request.</listitem>
- <listitem>For each file to be patched, either;
+ <listitem>その要求によって修正される問題についての説明
+ (commit メッセージ用として。
+ パッチリリースがおこなわれる場合にはパッチリリースの
+ CHANGES ファイル用でもある)。
+ この要求によって処理される問題報告の一覧も含めます。</listitem>
+ <listitem>修正対象の各ファイルに関して、以下の情報。
<itemizedlist>
<listitem>
- <para>A
- <emphasis role="bold">full</emphasis>
- copy of the email message containing the commit
- message that was sent to
- <email>source-changes</email>
- . Use the mail archives if you no longer have a
- copy of the mail.</para>
- <para>If multiple revisions of a file are to be
- pulled up, include a
- <emphasis role="bold">full</emphasis>
- copy of each of the emails sent to
- <email>source-changes</email>
- . The changes in the specified revisions will be
- pulled up to the release branch.</para>
- <para>Please do not submit requests like
- <quote>everything up to revision N,</quote>
- or
- <quote>make it match -current.</quote>
- Requests like this are more difficult because
- releng needs to figure out the starting revision
- for the pull-up (for the commit message). That can
- be complicated by other revisions having been
- pulled up, for instance. It's better to have the
- person requesting the pull-up do that, because they
- already know what they want pulled up. Also, in the
- latter example, there's the possibility that
- someone will commit something to the file between
- the time that the request is made and the time that
- it is processed, which may lead to
- insufficiently-tested changes being pulled
- up.</para>
- <para>If there are conflicts involving anything
- other than RCS IDs the pull-up request will be
- rejected and you will be asked to resubmit
- it.</para>
+ <para><email>source-changes</email> に送られた、
+ commit メッセージを含んだ電子メールの
+ <emphasis role="bold">全文</emphasis>のコピー。
+ メールがあなたの手元に残っていない場合は、
+ メールアーカイブからコピーしてください。</para>
+ <para>複数のリビジョンを pull up するファイルについては、
+ <email>source-changes</email> に送られた、
+ commit メッセージを含んだ電子メールそれぞれについて、
+ <emphasis role="bold">全文</emphasis>のコピー。
+ 指定された各リビジョンでの変更点が、
+ リリース枝に pull up されることになります。</para>
+ <para><quote>リビジョン N にすべてをあわせた更新</quote>
+ とか、
+ <quote>-current にあわせた更新</quote>
+ といった要求を提出しないでください。
+ こういった要求は、releng が
+ (commit メッセージに書くために)
+ pull-up がどのリビジョンからを対象としているのか、
+ 調べなければならず、対処が困難になってしまいます。
+ たとえば他のリビジョンがすでに pull-up されていると、
+ さらにわかりにくくなってしまいます。
+ pull-up 要求をする人は、
+ 何を pull-up したいかを知っているわけですから、
+ 要求者本人がこれら必要な情報を用意したほうがいいでしょう。
+ さらに後者の例では、
+ 要求が提出されてから処理されるまでの間に、
+ pull-up の対象のファイルに対して、
+ 他の誰かが (trunk で) 変更を commit する可能性もあります。
+ その場合は、十分テストされていない変更まで
+ pull-up されてしまうかもしれません。</para>
+ <para>RCS ID 以外について、衝突が発生する場合は、
+ pull-up 要求は却下され、
+ 提出しなおすよう求められます。</para>
</listitem>
<listitem>
- <para>A patch file to be applied to the source
- tree. (If the patch just implements pull-ups of
- revisions that were otherwise prevented by
- conflicts, those revisions should be noted.)</para>
- <para>The patch file will be applied with patch. If
- any special instructions are necessary to apply the
- patch, they should be included in the pull-up
- request.</para>
- <para>If there are any conflicts at all, the
- pull-up request will be rejected and you will be
- asked to resubmit it.</para>
+ <para>ソースツリーに適用するためのパッチファイル。
+ (そのパッチが、衝突が発生するリビジョン間の
+ pull-up をしているだけである場合は、
+ そのリビジョンを記しておきます。)</para>
+ <para>パッチファイルは、patch コマンドを使って適用されます。
+ パッチの適用に関して特に説明が必要な場合は、
+ pull-up 要求にその説明を含めてください。</para>
+ <para>何であれ、衝突が発生する場合は、
+ pull-up 要求は却下され、
+ 提出しなおすよう求められます。</para>
</listitem>
</itemizedlist>
- In general, it's best if all of the file and revision
- information is placed together, near the beginning of
- the pull-up request. It shouldn't be necessary to dig
- through a huge patch to figure out what steps to take.
- Additionally, if a patch really is just the difference
- between two revisions and applies cleanly, that should
- be noted (and a patch to do the same thing should be
- omitted).</listitem>
+ 一般的に、すべてのファイルとリビジョンの情報を、
+ pull-up 要求の冒頭のあたりに、まとめておくのが最善です。
+ 何をすればいいかを調べるために、
+ 巨大なパッチから発掘しなければならないようにしてはいけません。
+ さらに、パッチが 2 リビジョン間の差分そのままであって、
+ きれいに適用できる場合は、そのことを記しておきます
+ (そのようなパッチは、省略します)。</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
- <para>With that said, it is also true that the release
- engineering team will do their best to be accommodating in
- accepting minor variations of the above. Do however note
- that the release engineering team will typically have their
- hands more than full enough during the release cycle, so
- please do not deviate too far afield from the requirements
- set forth above.</para>
+ <para>以上のように述べましたが、
+ リリースエンジニアリングチームは、
+ 若干異なるものも受け入れるよう、最大限の便宜をはかるようにするというのも、
+ また事実です。しかし、リリースサイクルの期間中、
+ リリースエンジニアリングチームは並外れて多忙となりますので、
+ 上述した要件から大きく逸脱するようなことはしないでください。</para>
</sect3>
<sect3 id="examples">
- <title>Examples of Good Pull-up Requests</title>
- <para>Here is an example of a good pull-up request:</para>
+ <title>よい pull-up 要求の例</title>
+ <para>よい pull-up 要求の例を、以下に示します。</para>
<programlisting>
From: Matthias Scheler <tron@NetBSD.org>
To: "NetBSD 1.6 Pullup Requests" <pullup-1-6@NetBSD.org>
@@ -237,56 +233,54 @@
</programlisting>
- <para>In detail:</para>
+ <para>以下、説明です。</para>
<itemizedlist>
- <listitem>The subject gives a short description of the
- purpose and the urgency.</listitem>
- <listitem>It includes the commit message for both
- changes.</listitem>
- <listitem>It contains a patch for the revision which
- cannot be applied directly.</listitem>
- <listitem>The original committer received a copy of the
- pull-up request.</listitem>
+ <listitem>subject は、
+ その効果や緊急度についての手短な説明となっています。</listitem>
+ <listitem>各変更について、
+ commit メッセージを含めています。</listitem>
+ <listitem>変更を直接適用できないリビジョンについては、
+ パッチをつけています。</listitem>
+ <listitem>元の (trunk の) 変更を commit した人が、
+ pull-up 要求のコピーを受け取っています。</listitem>
</itemizedlist>
</sect3>
<sect3 id="security-fixes">
- <title>Pull-up Requests for security fixes</title>
- <para>Pull-up requests for security fixes should have the
- keyword
+ <title>セキュリティーの修正に関する pull-up 要求</title>
+ <para>セキュリティーの修正に関する pull-up 要求では、
+ リリースエンジニアリングチームが簡単に識別できるように、
<emphasis>security</emphasis>
- in their subject line so that release engineering can
- easily recognize them. Depending on the urgency it might
- also be a good idea to try to contact one or more release
- engineers directly and point them to the ticket.</para>
+ というキーワードを subject 行に含めてください。
+ 緊急度によっては、一人または複数のリリースエンジニアに、
+ チケット番号を直接連絡してもよいでしょう。</para>
</sect3>
<sect3 id="perform">
- <title>How to actually perform a CVS pull-up</title>
- <para>For a given release cycle, typically in the
- beginning, developers may be expected to do pull-ups
- themselves after approval from the release engineering
- team. A
- <ulink url="howto-pullup.html">detailed example</ulink>
- with explanatory comments of how this is done is
- available.</para>
+ <title>CVS pull-up が実際にどのように実行されるか</title>
+ <para>リリースサイクルにおいて、特にその初期には、
+ pull-up 要求をリリースエンジニアリングチームが承認した後、
+ 開発者が自分で pull-up を実行することとされることがあります。
+ pull-up をおこなう方法の、
+ <ulink url="howto-pullup.html">詳しい例</ulink>
+ (説明のコメントつき) を用意してあります。</para>
</sect3>
<sect3 id="pkgsrc-releng">
- <title>Special issues for pkgsrc releng</title>
- <para>The usual pullup procedures are:
+ <title>pkgsrc releng 特有の事項</title>
+ <para>通常の pullup の手順は、以下のとおりです。
<itemizedlist>
- <listitem>Only security fixes pulled up</listitem>
- <listitem>Platform-specific fixes might be ok, but are
- clear second class citizens to the security fixes (i.e.,
- security fixes should be pulled up with higher
- priority)</listitem>
- <listitem>Noone pulls up their own request</listitem>
- <listitem>In case of doubt, ask
- <email>pkgsrc-pmc</email>
+ <listitem>セキュリティーの修正だけが pull-up されます</listitem>
+ <listitem>プラットフォーム固有の修正も可ですが、
+ セキュリティーの修正よりは格が下となります (つまり、
+ セキュリティーの修正のほうが高い優先度で
+ pull up されるということです)</listitem>
+ <listitem>個人的な要望を pull up することはできません</listitem>
+ <listitem>疑問がある場合は、
+ <email>pkgsrc-pmc</email> に質問してください
</listitem>
</itemizedlist>
</para>
</sect3>
</sect2>
</sect1>
- <parentsec url="../" text="NetBSD Developer Documentation" />
+ <parentsec url="../" text="NetBSD 開発者ドキュメンテーション" />
</webpage>