[debian-devel:17478] Re: パッチが Debian 特有かどうかの判断を自動的にはできないか（またはできるようにしないか）

[Nobuhiro Iwamatsu <iwamatsu@xxxxxxxxxxx>]

On Sun, 19 Oct 2008 11:44:14 +0900
"Noritada Kobayashi" <noritadak@xxxxxxxxx> wrote:

<snip>
> >>
> >> なんでこんなことを提案するかというと、先日の OpenSSL 問題など、upstream
> >> へのマージをもっと働きかけておけばチェックできたであろう distribution specific
> >> である必要が無いパッチがまだあるだろう、という考えが浮かんだからです。
> >
> > Debian-Specific: yes なものは、Debian 特有のパッチで、ないもの( or no )なものは
> > Upstream に返す必要があるパッチ、ということでよろしいでしょうか。
> 
> やまねさんの記述「upstream での適用を意図しているかいないか」に、
> 岩松さんの解釈「upstreamに返す必要があるかいないか」は合っていると思います。
> しかし、自分はむしろ、「upstreamに入った変更か否か」で切り分けるべきではないかと思います。
自分も、小林さんといっしょなんですけどね....。うまく説明できなくてすみません。
Upstream には返すべきでしょう。というか、そういう風に決まっていますし。
自分は、Debian 特有のパッチには、Debian だけに摘要されるパッチだけではなく、Upstream
によって取り込まれなかったパッチも入る、と思っています。
なので、わざわざマーキングをぜずに、残っているものは Debian 特有パッチでいいんじゃないの、
という考えです。

> 
> パッチが行ベースなので、もちろんパッチを移植することに意味があるかどうかは厳密には不明ですが、
> それはさておき、
> とりあえずupstream (新バージョンなりVCSのメインツリーなりリリースブランチなり) に入った変更が
> パッチとしてDebianに入った場合、それは「upstreamのお墨付きを得ている」と言えるので、
> 意味があると思います (もちろん、厳密にいえば変更が他の変更と関わっている可能性もあるので、
> それで安心しすぎるのは危険ですが)。
> 特に修正については、コードを熟知したupstreamが取り込んだもののほうが安心できると思います。
> 一方で完全にDebianのための変更、
> あるいはupstreamの修正内容がそのままでは当たらないので多少なりとも手を加えた変更には、
> それなりに注意を払う必要があります。
> 
> 特に今のようなフリーズ下の状況だと、
> 「新しいバージョンでの修正内容を見てそれを移植」というのは、
> 多くのメンテナがよくやっているかなと思います。
> 
> upstreamでの運用を意図した変更でもupstreamにrejectされることはあるし、
> パッチをレビューしてもらってアドバイスをもらって再投稿というのはよくあるので、
> 「upstreamに返す予定」だけでは必ずしも信頼性は高くないと思います。
> 

予定、じゃなくて、返してから Debianパッケージを作成しよう、という考えなのですが。
なので、changelog を BTS、パッチ名、ML投稿先URL でチェックしようという提案をしてみました。

あと、パッケージングと通常の開発では開発手法、順番が異なるので、パッチレビューしてもらって...
というのも、なんかちがうかな。
メンテナは自分のコードに責任を持つべきだと思っているので、その辺はどうなのだろか。
この辺はメンテナ、スポンサの責任になるという運営で成り立っていると。

> > 個人的な考えですと、パッチにマーキングしなくても、パッチ全部送るという手があると
> > おもうのですが、いかがでしょうか。
> > で、取り込まれなかったり、交渉がうまくいかなかったら、パッチはそのままDebian パッケージ
> > の中に残ったままになると。
> > 今はそんな感じで動いているとおもうのですが、ちがうのかな。Debian 社会契約 第2項があるので。
> >
> >>
> >> 現状、http://patch-tracking.debian.net のような取り組みもあるようですが、
> >> パッチじゃないものまでまとめて見ちゃってるのでまだまだ使い勝手が良くは
> >> ありません。
> >>
> >> もう少し機械的に判別するためには
> >> ・upstearm でマージすべきかかどうかの情報
> >> を含んでいた方が楽かと思いました。
> >>
> >> ＃その情報がまだ無いとしたら、そもそもそのパッチはチェック自体がされていない
> >> という証拠にもなります。
> >
> > やりたいことは、Debian のパッチが Upstream に送ったか、をトラッキング
> > する方法はないか、ということだとおもうのですが、いかがでしょうか。
> > やまねさんの提案は良いんですけど、パッチを送ったかどうかまでの判断はできないですよね。
> >
> > 例えば、パッケージにパッチを入れる際には、BTSとMLへのURLを changelog に書いておかない
> > とだめ、とか。それを lintian でチェックするなどのシステムがいいかな、と思いました。
> > # URL が正しいかはおいといて。
> 
> dpatchでもquiltでも、パッチのヘッダにコメントを書けますよね。
> 少なくとも自分はそれをきちんと書くようにしていますし、
> おそらくそうしているのが普通のメンテナだと思います。
> 「きちんと」というのは、
> 「パッチのauthor」「upstreamに取り込まれている場合はコミットを示すリビジョン番号など」
> 「議論があった場合はその参照先」「パッチの意図」を明記する、という意味です。
> これはVCSでのコミットログを書くのと同じ感覚ですよね。

けど、そのルールは決まっていませんよね。
これらを構文解析できるようなルールを作りませんか、というのがやまねさんの提案だと思います。

あと、別のメールにも書きましたが、パッチだけに重きをおくとログが参照しにくくなるので、
パッチだけに書くのは個人的には反対です。

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

-- 
Nobuhiro Iwamatsu