いいじまです。 ヒートアップしていますが… > > roff ファイルをメールに付けない場合、チェックする人は、Git リポジトリを > > ブラウザで見に行くだけでは足りません。一つ一つ roff ファイルとして > > 落としてきて、それを man コマンドで見なければならないわけです。 ... > ちょっと矛盾していませんか？ > [JM:03386] > > 何を提出するかは、私の以前のメール、たとえば 2021/02/22 の > > [JM:02054] Re: [POST: RO] util-linux, dmesg > > などを参考にしてください。 > > 上記を拝見すると、添付ファイルとして tarball があって、 > roff ファイルを入手して確認するんですよね？ [JM:02054] あたりでは確かに、tarballがついていますね。 > それって man コマンドを使って確認するのではない > のですか？ （矛盾してても、特に問題視はしません。） まず大前提として、訳文が正しいかどうかの確認だけなら、manで整形せずともroffソースを直接読めば足ります。 次に、正しく整形できるかどうかの確認はML参加者の誰か（ミニマムとしては訳者本人と誰かもう一人）が行うだけで済みますが、訳語の確認はML参加者全員に期待したいところです。この2つの違いを再確認願います。 添付の可否について。gitリポジトリの中に入っているroffファイルはgitアプリなしでもブラウザで取り出せますが、添付してくれたほうが「PCユーザにとって」手間が省けることは確かです。一方、移動中にスマホでメールを読み書きするしかできないような人の場合、「拡張子.txtをつけて、pkzip形式で圧縮」でないと基本的に解凍・解読できません。そこまでの配慮を求めるのは、訳文を投稿する側にとって逆に負担になりそうです。添付用のzipファイルを作るシェルスクリプトを用意してもいいとは思いますが。 妥協点としては、git pushした時点でそのロケーションへのポインタ（特に、webブラウザで閲覧するためのURL）をMLに投げていただければそれで足りるように思います。URLの生成はスクリプトで行えばいいでしょう。 ☆ ☆ ☆ 以下、与太話。 > Linux カーネルや GNU gcc の開発者が > MLにソース添付してレビューすると思いますか？ その手のプロジェクトと比較すること自体に無理があるとは思いますが（コード開発の場合は実機で走らせないと検証できないのに対して、訳文の検討に実機は必要ない）、「Linux カーネルや GNU gcc」でも場合によっては開発中のソースの抜粋（さすがに全文ではない）なり、あるいは各種テスト用のコードなりををMLに投げることは当然あると思いますよ。 なのでこの例は、二重の意味で的外れかと。 これに限らずここ1-2ヶ月くらいのmatsuandさん、どうもかなり苛立っていて喧嘩腰の投稿が目立つように感じられるのですが、そう感じるのは私だけでしょうか？ -- 飯嶋 浩光／でるもんた・いいじま ＠ PC IIJIMA Hiromitsu, aka Delmonta Email <delmo****@denno*****>
Fork