[debian-devel:15042] Re: CFA: Cleaning up Debian JP tree about woody-jp/sid-jp

[ISHIKAWA Mutsumi <ishikawa@xxxxxxxxxxx>]

むつみです。

>>>>> In [debian-devel : No.15041] 
>>>>>	Atsuhito Kohda <kohda@xxxxxxxxxxxxxxxxxxxx> wrote:

>> >      2a) woody base freeze (相当)から一週間後
>> >      2b) 1.1 のアナウンスが行われてから一ヶ月後
>> > 
>> >   上記 2a) 2b) のどちらか「あとに」発生した事象[2]のタイミングで
>> >  以下を行う。

>> Debian にも JP にもパッケージがある身にとってはちょっと
>> 厳しいですね。2a) の一週間後は少なくても一月後ぐらいは
>> 欲しいですね。

 ???

 「woody が base freeze するまでの期間 + 1 週間」or「この提案が成立し
てアナウンスされてから 一ヶ月」のどちらか長い方 => 「最低限一ヶ月ある」
のですが、それでは短いということですか?

>> >   2.1b) 
>> >     Severity: important 以上の JP Bug リポートのあるパッケージを
>> >    リリースクリティカルバグだとみなし[3]、woody-jp からの削除。

>> リリースしないので woody-jp/sid-jp の区別はあまり意味
>> ないような気がするのですが。

 では woody-jp というのは 「どういう意味」で存在するものですか?
(どういう位置づけ?)

 区別しなくていいのであれば sid-jp だけでいい?

>> 現状では自動的なんですよね？

 えーと ここでいう「自動的」というのは いったいなんでしょう?

>> リリースクリティカル，の意味も JP では違ってしまうと思い
>> ます。

 どう違いますか?

>> 例えば i386 以外で build できない，とかいうのは
>> リリースしない JP ではそうクリティカルでないような(^^；
>> (べっ，別に ewb のことではありません。一般論です ^^；)

 要するに i386 以外は切り捨てろということですか?
 (という風に聞こえるんですが)

 「JP リリースしない」ことと「『i386 以外で build できないというバグ』
は問題のあるバグではない」ということがなぜ 関連するのか理解できないの
で説明してください。

>> メンテナンスされててバグがあるのは良いのではないでしょうか？

 メンテナンスされててもリリースクリティカルなバグがあれば woody からは
削除されますね、debian.org では。



 要するに、この提案の最大の目的はあまりにもメンテナンスされてないゴミ
パッケージだらけの状態に陥ってしまっている JP tree を整理したい
(= 意味のあるパッケージは残した上で、いらんもんは削除) ですが、主観
に頼って、消す消さないをやってると いっこうに進まないしもめる原因
なので、定量的な一定の線を引いて整理しましょうということです。


>> メンテナンスされててバグがあるのは良いのではないでしょうか？

 ですので これはもっともな意見ですし同意するところではありますが、
そこで思考を停止しちゃダメで これを 客観的にはかれる基準を提案して
ください。

 元々の提案では 2 つの基準で この振り分けを行うことを提案してる
わけです。

 一つめは、control の JP フィールドのにより、そもそも「メンテナンスが
行われていない」パッケージを選別すること。

 二つめは、「リリースクリティカルなバグ」を利用することで ひどいバグが
あるのもを選別すること。

 香田さんが気にしているのは、後者でしょう。

 で、そうすると

 1) 「(JP 的な)リリースクリティカルなバグ」と呼んでいるもの
   を利用して バグのあるパッケージを tree から除外することの是非

 2) そもそも 「(JP 的な)リリースクリティカルなバグ」と言ってるも
   の基準はなんじゃらほい?

という議論い帰着するはずですが 違いますか?

 この提案では 1) は 是認ですね。
 2) に関してですが、 そもそも この提案の中で書いてますが、現状では
debian.org のリリースポリシーに照らし合わせて、その基準で投げられて
いる(はずの)バグレポートを基準に 同様にリリースクリティカルバグを
定義している ことになっている つもりです。

 ただし、一点この方法で問題があるとすれば、JP BTS のシステム上の問題で
severity: serious が扱えないために、severity: important を境界
にしていることでしょうか。見る限り、現状 severity: serious 相当の
バグレポートは ほぼ severity: important で投げられているようですし、
もし それで問題があるということなら severity: grave 以上ということに
して 現在の JP BTS にあるバグレポートを整理して  必要な物を grave に
移すことで解決するので、重要なポイントではない気もします。

 そうすると、

「debian.org のリリースポリシーに照らし合わせて」

が、論点になるんですかね。であれば、そこの部分の明確な切り分けを
提案してください。

>> >  3.
>> > 
>> >    project-jp/experimental/orphaned に移動して一年を経過したものに
>> >   関しては削除を行う。
>>
>> これは一年も待たなくて良いような。2002 年中ぐらいでは？

 まぁ これはいつでもいいんですが「十分な期間をおいて」な つもりなので、
一年に固執する理由はまったくありません。

-- 
いしかわ むつみ
 <ishikawa@xxxxxxxxxxxxxxxx>, <ishikawa@xxxxxxxxxxx>, <ishikawa@debian.org>