芳尾です。
FYI なんですが、
ついこないだから -devel@.org で、JP Merge に関する議論があっているんで
すが、Wichert の 見解の Summary がでてました。
むっちゃ要約すると、
* 時間がちょっとはかかるだろうが、完全な Debian の I18N を目指
すためには、-ja というパッケージを安易につくるのではなくて、
上流の開発者やDebian.org のメンテナと連絡を密にとって、マー
ジするのが望ましい。
てなことをいっとります。
で、
* Debian.org のメンテナの反応が悪い場合
なんどもつつく、またその一方で upsteam の作者と連絡をとる。
* パッチの作者が別にメンテしている場合
FSF の長い伝統では、 `release fast, release often' なんじゃ。
パッチをいつまでも持っとくことは生産的とはいえへんで。
どうしてもそうせざるを得ない場合(たぶん、Mule の例が念頭にあるのではな
いかと)以外は、きちんとマージしようぜ、といっておるようです。
ご参考までに。
ではでは。 ---- Yours, K.S.Yoshio
mailto:shishamo@xxxxxxxxxxxxxxx
http://www2.osk.3web.ne.jp/~shishamo
Key fingerprint = 3C 3C 1C E6 B1 65 53 58 A3 B3 6A ED BA E4 54 52
--- Begin Message ---
- From: Wichert Akkerman <wichert@xxxxxxxxxxxxxxxx>
- Subject: Debian-JP discussions; lets wrap this up
- Date: Wed, 1 Sep 1999 14:54:37 +0200
- Resent-cc: recipient list not shown: ;
- Resent-date: 1 Sep 1999 14:04:25 -0000
- Resent-from: debian-devel@lists.debian.org
- Resent-message-id: <dKKFhD.A.zxD.oJTz3@murphy>
- Resent-sender: debian-devel-request@lists.debian.org
- X-envelope-sender: wichert@xxxxxxxxxxxxxxxx
- X-loop: debian-devel@lists.debian.org
- X-mailing-list: <debian-devel@lists.debian.org> archive/latest/43648
- X-uidl: 4cd4944daabaeee7cdcfacb0b087b78b
- References: <19990830143903.A17794@xxxxxxxxxxxxxxxx> <19990831101818U.kohda@xxxxxxxxxxxxxxxxxxxx> <y5a671vzonm.fsf@xxxxxxxxxxxxxxxxxxxx>
- Message-id: <19990901145437.L21826@xxxxxxxx>
- User-agent: Mutt/1.0pre1i
Okay, we've been discussing this for a while now and I think it's time to wrap this one up. All arguments have been made by now and it's been a very informative discussions for both sides. We (Debian) are very happy with the hard work that Debian JP has done and is still doing. However, as we just discussed, the current way that Debian JP is being integrated with Debian can use some improvements. What seems to happen a lot right now is that packages are being forked and *-jp packages are appearing. This seems to be done for two reasons: package maintainers not responding timely to bugreports from JP-maintainers, and people making multibyte patches don't consider their patch fit for inclusion and maintain it seperately. Needless to say I disagree with both reasons. Maintainers not responding in time is a problem and unfortunately there is not much to be done about that, except reminding them occasionally, and trying to work directly with the upstream maintainer. On the second reason: it has long been a motto of the Free Software community to `release fast, release often'. Holding on to a patch could work counter-productive. Only if for some reason merging is not an option, only then proceed with posting an intent-to-package and creating a new package. This will indeed slow things down a bit, but I feel that the final result will be a much more integrated system and a lot less tension. Finally I also have a comment on the patches themselves: it seems that a lot of the multibyte-patches contain changes that are not related to multibyte support but do things like add support for DOS and Windows systems or change generated files (like configure, config.h.in, Makefile.in, etc.). This makes it unnecessary hard to merge those patches. Wichert. -- ============================================================================== This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: wichert@xxxxxxxxxxxxxxxx WWW: http://www.wi.leidenuniv.nl/~wichert/Attachment: pgp0Lr27f8wFy.pgp
Description: PGP signature
--- End Message ---