backquotes

Yoichi NAKAYAMA yoichi @ geiin.org
2007年 9月 5日 (水) 08:36:17 JST


なかやまです
別の話になりますが、いい機会だと思うので。

At 04 Sep 2007 23:21:57 +0900,
守岡知彦 / MORIOKA Tomohiko wrote:
> とりあえず、FLIM の変更に関しては、まず、emacs-mime-{ja|en} で議論して
> からやるのが良いんじゃないでしょうか?
> 
> ;; 枝の持ち主以外がいきなり commit するのは望ましくない気がします。
> 
> ;; また、短期間のうちに機械的に commit しちゃうのを見てると、十分にテ
> ;; ストされているのか不安になります。 (^_^;
> 
> 実装面に関しては、私自身として review できてない部分も少なくないのです
> が、eword-encode.el の該当個所に関しては luna で書き換えるのが良いかな
> と思います(あるいは、関数でも良いかも)。
> 
> ;; これは、やってみようと思います。
> 
> P.S.
> 
> たまに出てきてでしゃばって申し訳ないです(mail 環境がすっかり崩壊して
> いるので、普段、記事も読めてないもので(^_^;)。ただ、枯れたソフトウェ
> アにおける品質維持のための手続き上の懸念を少し持ったもので。動機の点で
> はおそらく同様だと思うので、プロセス上の問題点に関してご配慮して頂けれ
> ば幸いです。

ここで許可をとったわけではないですが、過去数年にわたり flim-1_14-rfc2231-encoder
枝に対して flim-1_14 の変更のマージ作業を行ってきました。(e.g. [emacs-mime-ja:02029])
RFC2231対応は将来的には flim-1_14 への導入の可能性もあると考えており、
枝の変更分だけを区別できるように個別の修正をマージするのではなくリリース
タグから一気にマージするように進めてきています。今後もそのように進めても
問題ないでしょうか。

P.S. (というかこちらが本題)
最近はRFC2231ってどうなんでしょうか?少し(だいぶ?)前にMew方面で話題に
あがっていた気がしますがちゃんと追ってていません。
# 職場では相変わらずlimit-1_14使ってますが。
-- 
Yoichi NAKAYAMA





More information about the APEL-ja mailing list