NOEMBLEM/エンブレムが設定されていません。

メールの詳細(トピック表示)

まとめ

投稿者:canadaさん  2009/12/08 05:00  MLNo.1108   [メール表示]

金田です。
私の考えをまとめておきます。間違いがあると思うので、指摘して下ると助かります。

■現状
sourceforgeで管理
なのでCVS
文字コードはEUC-JPかUTF-8
修正は、誰かが手動でperldoc.jpにアップロードしている
なので反映が遅い

■私の考え
gitで管理
なのでGit
文字コードはutf8のみ
だと困る人がいるのでCVSは残す。ただしコミット専用。
git cvsimportを使ってgitへい移行。文字コードはこの時自動修正
修正は、即座に反映される(現在のperldoc.jpは新ポータルに置き換えてなくす方向で)
新ポータルは定期的にgit pullするので常に最新
オリジンマスタはgithub。気に入らなければ好きにCloneすればよい(gitの利点)
sorceforgeからgithubに移行、全員コミッタにして誰でも編集可能にする。
Wikiと言ってる人は、githubの簡単エディタ機能で我慢してもらう(かんたんにすぐ修正、即座に反映。「誰でも」ではないが)

とりあえずこんなところ。あとGitはただの流行りものではないのは理解して欲しいです。
svnでLinuxプロジェクトで正常に機能しているシステムです。
--
Canada, Masakatz


 読み込み中...
最新の10件 1 2
  • MLNo.1112   canadaさん  (0) 2009/12/08 07:27  [メール表示する]
    > 金田さんのお考えはだいたいわかった気がします。

    ありがとうございます。

    > とりあえずgithubにプロジェクトを作って、

    はい。すでに今git cvsimportやってるところです。何時間経っても終わらないのでひたすら待ちです。
    終わったところでgithubに移します。

    CVS -> gitと文字コード変換は何度も言うように責任を持ってやります。ダウンタイムがあってもOKなら逆もできると思います。
    --
    Canada, Masakatz

  • MLNo.1113   canadaさん  (0) 2009/12/08 07:39  [メール表示する]
    本題から外れますが、Gitのメリットをもうひとつ言えば、ブランチを切って、書きかけの翻訳を
    リポジトリ上に置いて、分散翻訳できるところですかね。
    CVSでもブランチくらい切れた気がしますが、マスターとのマージがハンパなく楽です。
    要は翻訳が完成したら本番に簡単にがっちゃんこできるってことです。

    ですます調を手分けして直すブランチ、なんてのも気軽に切れます。Gitのブランチは他のブランチ
    のように大仰なものではありません。サクサク切ってじゃんじゃんマージや削除をしていく性質のものです。

    プログラムはドキュメントの一種ですから、かつてCVSがドキュメント管理に向いていたように
    Gitもドキュメント管理との親和性は高いんですよ。

  • MLNo.1116   iwaimさん  (1) 2009/12/08 11:59  [メール表示する]
    岩井です。

    2009年12月8日7:39 Canada Masakatz :
    > 本題から外れますが、Gitのメリットをもうひとつ言えば、ブランチを切って、書きかけの翻訳を
    > リポジトリ上に置いて、分散翻訳できるところですかね。
    > CVSでもブランチくらい切れた気がしますが、マスターとのマージがハンパなく楽です。
    > 要は翻訳が完成したら本番に簡単にがっちゃんこできるってことです。

    そもそも翻訳物とプログラムはかなり違うというのを理解していないんだと思う。
    推敲していないもの用のブランチがあれば問題なんて発生しないですよ。
    CVS使ってもマージが大変になることは全然想像できない。
    だって、翻訳箇所については作業分担するでしょ?

    Gitが流行りものというだけではないというのは知っているつもりだけど、
    一方で、金田さんや大前さんは「流行りだから採用しとけ」というぐらいにしか
    考えてないようにみえるんですよね。
    ま、CVSリポジトリの方も残るんだったらまったく問題のでやっていただけたらいいと思う。
    # 実際はじめているみたいなのでまずはこれで終わりなのかな。

    --
    いわい

  • MLNo.1118   canadaさん  (0) 2009/12/08 12:39  [メール表示する]
    私の発言をどうナナメ読みしたらそうなるのか分かりませんが……。
    Gitは現場でバリバリ使っててこりゃCVSやSVNを塗り替えるものだという確信の元で言ってます。
    (っていうかWikiなんて流行りものどころか廃れものだし)

    んで今の予定ではCVSリポジトリは投稿専用になるので残りませんよ。
    GitからCVSリポジトリに差し戻す作業は想定していません。

    git cvsimportも朝の5時くらいからやっててまだ終わりませんから
    (ネットワーク絡みでなんかおかしいのかも知れないから一回リポジトリを持ってきてみているところ)
    実用できないかもしれません。まあとにかく手動ででもCVSからGitへの移行は
    私が責任を持ってやります。これは約束します。逆は保障しません。

    2009年12月8日11:59 IWAI, Masaharu :
    > 岩井です。
    >
    > 2009年12月8日7:39 Canada Masakatz :
    >> 本題から外れますが、Gitのメリットをもうひとつ言えば、ブランチを切って、書きかけの翻訳を
    >> リポジトリ上に置いて、分散翻訳できるところですかね。
    >> CVSでもブランチくらい切れた気がしますが、マスターとのマージがハンパなく楽です。
    >> 要は翻訳が完成したら本番に簡単にがっちゃんこできるってことです。
    >
    > そもそも翻訳物とプログラムはかなり違うというのを理解していないんだと思う。
    > 推敲していないもの用のブランチがあれば問題なんて発生しないですよ。
    > CVS使ってもマージが大変になることは全然想像できない。
    > だって、翻訳箇所については作業分担するでしょ?
    >
    > Gitが流行りものというだけではないというのは知っているつもりだけど、
    > 一方で、金田さんや大前さんは「流行りだから採用しとけ」というぐらいにしか
    > 考えてないようにみえるんですよね。
    > ま、CVSリポジトリの方も残るんだったらまったく問題のでやっていただけたらいいと思う。
    > # 実際はじめているみたいなのでまずはこれで終わりなのかな。
    >
    > --
    > いわい
    >
    >
    > 【MLコミュホームページ】http://www.freeml.com/perldocjp
    >
    > --[PR]------------------------------------------------------------------
    > ◇◆◇◆ 憧れの4LDKや共用施設充実マンション    ◇◆◇◆
    > ◆◇◆◇賃貸じゃ難しい?理想の住まい探しは早めの資料請求で先手!◆◇◆◇
    > ◇◆◇◆ これから販売予定のおNewなマンション、即チェック ◇◆◇◆
    > http://ad.freeml.com/cgi-bin/sa.cgi?id=eQdPz
    > ------------------------------------------------------------------[PR]--
    > ■GMO INTERNET GROUP■ GMO INTERNET www.gmo.jp
    >
    >



    --
    Canada, Masakatz

  • MLNo.1119   Ktatさん  (0) 2009/12/08 13:17  [メール表示する]
    加藤です。

    gitを知らない人用の導入方法や、gitを?導入した場合の作業イメージっていうのを、
    先にドキュメント化したほうがいいんじゃないんですかね。
    イメージが共有できてないから、混乱する気がするんですけど?

    僕の心配は、gitにすることで参入障壁あがったらやだなぁってくらいですが。

    ちなみに、ちょっとずれますが、僕の理想的な翻訳作業は、オリジナル用のリポジトリを持っておいて、
    バージョンごとにタグをうつ。翻訳用のリポジトリを持っておく(オリジナルのリポジトリを持っておくのは、patch作るためです)。
    trunkは常に最新バージョンを翻訳。翻訳が完了したらバージョンごとにタグをうつ。っていう感じです。
    それだけで、十分じゃないかなと思ってます。

    んで、また、誤解っぽいところを指摘しておきます。

    > ■現状
    > sourceforgeで管理
    > なのでCVS

    プロジェクト開始当初、CVSが主流で、sourceforgeは、CVSしか使えませんでした。
    7年くらい前の話です。今は、Sourceforgeでも、git/svn 使えます。

    http://sourceforge.jp/docs/Gitの使い方

    Webから修正する機能はなさそうですけどね。

    > 修正は、誰かが手動でperldoc.jpにアップロードしている
    > なので反映が遅い

    perldoc.jp は1時間に1回(だったと思う) cronでリポジトリの内容を反映しているだけです。

    CVSリポジトリの修正を、「誰か」がやってます。

    誤訳等の報告を受けた時の話なら、gitだろうが、なんだろうが、
    反映が遅くなるのは、一緒だと思うんですけども?

    このプロジェクトで、反映が遅い原因を言うならば、
    誤字/誤訳等は気づいた人が勝手にcommitすればいい話なんだけど、
    あんまり、そういう雰囲気にはならなかった。
    そのため、メインの翻訳者が修正していたので、対応が遅れたり、
    放置されるってことがあった、ていうただそれだけな気がします。
    完全に人の問題であって、リポジトリ云々は関係ないと思ってます。
    Webから修正できればっていう話はツールの問題で、そこは参入障壁の問題でしょう。
    現状、sourceforge.jpに登録して、commit 権限をもらって、cvsをcheckoutして、修正。

    後は、翻訳物のフッタとかに、連絡先があったりなかったりという現状なので、
    連絡先がわからないという、その辺の問題もあるでしょう。

    今、現在の誤訳報告の流れって

    perldoc.jpの翻訳物 -> perldoc.jpトップ -> perldocjp.sourceforge.jp -> FAQ -> ML/BTS

    って、流れだと思うので、遠い。

    --
    Kato Atsushi (Ktat)
    mailto:ktat.is@…

  • MLNo.1120   iwaimさん  (1) 2009/12/08 13:20  [メール表示する]
    岩井です。

    2009年12月8日12:39 Canada Masakatz :
    > んで今の予定ではCVSリポジトリは投稿専用になるので残りませんよ。

    金田さん作成中のポータルサイトがperldocjp.sourceforge.jpのCVSリポジトリを
    直接みないという意味ですよね。
    白方さんや我々が、今のCVSリポジトリをそのまま使えるなら私としては問題ないです。

    たぶん、ユーザ権限的には消せる気もしますけど、そんな無茶はやらないでくださいね。

    > GitからCVSリポジトリに差し戻す作業は想定していません。

    はい。それでいいと思います。

    --
    いわい

  • MLNo.1121   canadaさん  (0) 2009/12/08 13:27  [メール表示する]
    んじゃ特に問題ないですね。perldoc.jpが置き換わった時にはCVSリポジトリの内容と
    perldoc.jpの内容が食い違ってくると思いますがそれは構いませんか?

    つまり修正を加える時は、ポータルなりGitなりからドキュメントを持ってきてそれを
    修正しなきゃならんということです。

    Ktatさん、色々ご教授ありがとうございます。どうも私は推測でものを言う癖があるようで
    今後気をつけます(と前にも書いた気がしますが)。

    Gitだったらタグ打たずにどんどんブランチを切ってく感じかなあとは思いました。

    2009年12月8日13:20 IWAI, Masaharu :
    > 岩井です。
    >
    > 2009年12月8日12:39 Canada Masakatz :
    >> んで今の予定ではCVSリポジトリは投稿専用になるので残りませんよ。
    >
    > 金田さん作成中のポータルサイトがperldocjp.sourceforge.jpのCVSリポジトリを
    > 直接みないという意味ですよね。
    > 白方さんや我々が、今のCVSリポジトリをそのまま使えるなら私としては問題ないです。
    >
    > たぶん、ユーザ権限的には消せる気もしますけど、そんな無茶はやらないでくださいね。
    >
    >> GitからCVSリポジトリに差し戻す作業は想定していません。
    >
    > はい。それでいいと思います。
    >
    > --
    > いわい
    >
    >
    > 【MLコミュホームページ】http://www.freeml.com/perldocjp
    >
    > --[PR]------------------------------------------------------------------
    > ◇◆◇◆ 憧れの4LDKや共用施設充実マンション    ◇◆◇◆
    > ◆◇◆◇賃貸じゃ難しい?理想の住まい探しは早めの資料請求で先手!◆◇◆◇
    > ◇◆◇◆ これから販売予定のおNewなマンション、即チェック ◇◆◇◆
    > http://ad.freeml.com/cgi-bin/sa.cgi?id=eQeRG
    > ------------------------------------------------------------------[PR]--
    > ■GMO INTERNET GROUP■ GMO INTERNET www.gmo.jp
    >
    >



    --
    Canada, Masakatz

  • MLNo.1122   iwaimさん  (1) 2009/12/08 13:29  [メール表示する]
    岩井です。

    2009年12月8日13:17 ktat :
    > 僕の心配は、gitにすることで参入障壁あがったらやだなぁってくらいですが。

    これは人それぞれだとは思います。
    私としては、Gitというよりも、githubを使うことで
    - 簡単にforkができる
    - PODをいい感じにHTML化してくれる
    というgithubのメリットが、そのままプロジェクトのデメリットとなると思ってます。
    つまり、みんなで別々に修正したものが、いろんなところでそれなりに見える。
    その結果、Google検索などで無数に検索に引っかかってしまい、もしかしたら
    (誰かが修正してくれている) 誤訳が掲載されているものが参照され続けるというところ。

    が、まあ、やってみればいいんじゃね? というのでええんちゃうかな、と。

    --
    いわい

  • MLNo.1123   iwaimさん  (1) 2009/12/08 13:47  [メール表示する]
    岩井です。

    2009年12月8日13:27 Canada Masakatz :
    > んじゃ特に問題ないですね。perldoc.jpが置き換わった時にはCVSリポジトリの内容と
    > perldoc.jpの内容が食い違ってくると思いますがそれは構いませんか?

    Japanized Perl Resources Projectとしては構わないんじゃないでしょうか。
    perldoc.jpの人が構うかどうかは知らないけれども。
    でも、それは我々Japanized Perl Resources Projectが気にするところではない。

    今まで、perldoc.jpやCPAN.jpが、Japanized Perl Resources Projectとは違うプロジェクトとして
    そのポータルを担ってくれていた点は1Perlユーザとしても、Japanized Perl Resources Projectの
    参加者としても感謝しています。

    そもそも、我々Japanized Perl Resources Projectのメンバーは
    「日本語への翻訳は少なくて残念だよね」
    というところから、 河馬屋二千年堂の川合さんなどが結成したプロジェクトです。
    # 確か。私は最初期にはいなかったので間違ってたらごめんなさい。
    # あと、川合さんが中心みたいな書き方ですが、個人的にはそれまでは
    # 川合さんが独自で訳していたドキュメントを参照してて印象深いから
    # 名前出しただけです。他にもプロジェクト運営を含めみなさんから多大な
    # 協力がなされていることは把握してます。

    Japanized Perl Resources Projectでは、当初はPerlユーザへの見せ方は
    それほど考えてない状況で、それが今まで継続している認識です。

    また、その後か同時なのかはわかんないですが、perldoc.jpやCPAN.jpが
    あったために、見せ方を気にする必要がなかったとも言えます。

    今後、Japanized Perl Resources Projectの成果物がperldoc.jpから
    参照されなくなった場合にどうするのかは我々Japanized Perl Resources Projectの
    課題なのでしょう。
    もちろん、今までにJapanized Perl Resources Projectにて翻訳なさってた方が
    金田さんがやるgithubでの翻訳側にcommitしていくのもまったく問題ないと思います。
    それは個人の判断ですから。


    > Ktatさん、色々ご教授ありがとうございます。どうも私は推測でものを言う癖があるようで
    > 今後気をつけます(と前にも書いた気がしますが)。

    気をつける気、全然ないじゃん。

    --
    いわい

  • MLNo.1124   Hippo2000さん  (0) 2009/12/08 15:43  [メール表示する]
    川合孝典です。

    呼ばれたようなので。

    perldocjpの最初のころの話は前のメールに記録が残っています。
    一番近いのはこのあたりかも?

    サマリ(2002/5/17-24)
    http://www.freeml.com/perldocjp/98

    >今まで、perldoc.jpやCPAN.jpが、Japanized Perl Resources Projectとは
    > 違うプロジェクトとして
    >そのポータルを担ってくれていた点は1Perlユーザとしても、
    > Japanized Perl Resources Projectの
    > 参加者としても感謝しています。
    このMLがあってその中の議論でSourceForgeに広がり、perldoc.jpやCPAN.jpが
    立ち上がったという順番だったと思います。
    いずれも、だれかが「こうあらねばならん」とやり立ち上げさせたというより、
    このMLでの議論を受けてボランティアでやってくれていたということで
    認識しています。

    SourceForgeのCVSに貯められている情報については「公開したい人はしなはれ」
    「利用したい人はしなはれ」というスタンスだろうと思っています。
    (違ったら指摘してください)
    私としてはSourceForgeのCVSは翻訳の作業場所というより結果の集積場所の
    イメージが強かったんですけどね。

    いずれにしても新しい方式で立ち上げてみて実績があがれば、自然と古いものを
    吸収する方向に動くんじゃないでしょうか。もちろんその逆もありうるでしょう
    し、まったく違う動きになるのかもしれません。

    私自身は、この何年も日本語訳もやっていないので、何しても
    様子見になってしまうのですが...
    意欲を持った人が新しい方式で翻訳をするのも、公開するのも大いに結構だし
    喜ばしいことだと考えています。
    ただいくらその人がいいと思っていても「こうあらねばならぬ」と他人に
    強要するのは感心しませんし、まったくPerlらしからぬことだと考えています。
    #そういう人には逆らってしまう天邪鬼でもあるので

    ついでに私はJapanized Perl Resources Projectを「立ち上げた」という
    ほどのことはありません。単なる管理人として動いていた程度です。
    あちこちに日本語訳があってどこを見ればわからないというのは
    困るよねというのが、そもそもこのMLのスタートです。
    (スタートも私じゃないんですよ)

    Perlドキュメント日本語訳ML発足
    http://www.freeml.com/perldocjp/1

    ===================================================
    川合 孝典 (Hippo2000)

    ===================================================

最新の10件 1 2
【PR】ステキなブログ掲示板で楽しく話そう話題の日記最新のブログ人気の日記
4LDK超ってこんなに広い?/SUUMO