[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[SUMMARY] repository for development
開発者用CVSのthreadについて、summaryしました。あくまで、私からの
視点からでsummaryしてますので、偏っているところは訂正して下さい
改行は見易いように適当に変更してあります。
-- jp.netbsd.orgのマシンについて
soda:837> 作業者のために、CVS リポジトリも配ることになるので、やはり
soda:837> jp.netbsd.orgで提供して貰えると、分かりやすくて嬉しいです。
ura:857> foo.jp.netbsd.orgであれば分かりやすいと思います。
これについては、あまり議論がされていないのですが、CVSマシンに
jp.netbsd.orgが付くのは構わないのでいいのかな？
-- moguについて
soda:837> 現在の mogu の構成ならディスク容量的問題はないと思います。
soda:862> というか、mogu って、割と強力な計算機リソースを持っているので、
soda:862> これを WWW の /cvsroot だけに利用するのは、すごくもったいない
soda:862> ような。:-)
tsubai:872> こういうこともあるだろうと思ったから /cvsroot が 4G も
tsubai:872> あるんだけど…。
ayamura:879> 迷惑問題とかがなければ mogu でやりのが理想的なのでしょうが…。
皆さん、リソース的／場所的には問題ないと考えていますね。後は、政治的に
クリアにする必要があると。それで、IRIについてのまとめは別に分けました。
-- アカウントの発行について
ura:857> 開発用にはアカウントを作ると考えた場合に、今のagreementは
ura:857> 敷居が高いと思います。開発用のアカウントの発行は、プロジェクト
ura:857> リーダー(s)の判断で必要と思った人にアカウントをすぐに発行できた
ura:857> 方が良いでしょう。
soda:871> 開発者の場合でも、agreement は、別種のものを用意する必要はなく、
soda:871> 現在のものと同じで良いと思ってます。
seirios:873> この辺は、別途 jp.netbsd.org の規約を考えないといけないので、
seirios:873> 一緒にやっちゃいます。
soda:874> どんな場合でも、ある程度のセキュリティを確保する必要があります
soda:874> から、開発リーダーが指名するだけじゃなくて、アカウントを取得
soda:874> しようとする人がagreeする必要があります。
開発者も何らかのagreementを出すとして、それに、今のagreementをそのまま
適用するか否かが議論の分かれどころでしょうか？
私の趣旨は、「同一マシンは同一のagreementで」です。
-- IRIについて
seirios:865> 作業場所を提供するようなことは書いてないんですよ。サーバーの
seirios:865> メンテナンス一般は稟議書に書いたんだけど。
seirios:865> 僕の考えを言いますと
seirios:865> 1: 作業 account が増えるとセキュリティー保持が難しくなる
seirios:865> 2: jp.NetBSD.org からの社内に対する攻撃が発生すると場所を提
seirios:865> 供しにくくなる
tsubai:872> これはほぼ問題ないでしょう。ここ、完全に外部だもの。
tsubai:872> ちょっとコワいのは ping -f ぐらいかな。
seirios:865> NetBSD の開発者は比較的モラルが高く、大人が多いので、「今の
seirios:865> 所」問題は無いと思っていますが、先のことも多少は考えると
seirios:865> なやましい。この紐が jp.NetBSD.org のお金で動いている紐で
seirios:865> あれば自己責任だけ取れば良いから問題は無いでしょうけど、
seirios:865> ドネーションベースでやるわけですからどうしても「contributerには
seirios:865> 迷惑をかけてはいけない」
sakamoto:869> ということもわかりますので、moguにはこだわりません。
soda:871> なるほど。
soda:871> iri.co.jp では無理かもしれないわけですね。
seirios:873> jp.netbsd.org が「協力」しているのは問題ないと思いますが、
seirios:873> 「提供」しているのであれば、どこでも同様の問題が起こる
seirios:873> 可能性があると認識しています。
seirios:873> そして、起こったら終りというのはせっかくこれだけアクティビ
seirios:873> ティーが高くなったんですから勿体無い。起こらないようにするのが
seirios:873> 正しい方向だと思っています。(個人的見解)
これが今回の議論の中で一番の焦点ですね。問題としては
- JNUGが任意団体として一人立ちしていない
- JNUGとIRIのハウジングのdonationを受けるに当っての契約(になるの
かな)がきちんとされていない
- JNUGからIRIに対して要望が出せない
あたりに集約されますでしょうか？＞皆さん
JNUGとIRIの関係がすっきりすれば、IRIにJNUGが行ないたい作業として
開発者用CVSの公開を要望としてあげることは可能ですか？ ＞ほ
-- IRI以外の場所について
soda:871> やっぱり、こういうのは大学とかの方が良いのかな。
soda:871> どなたか、そこそこ太い線を持っている大学 (利用ポリシーが許すので
soda:871> あれば大学じゃなくても良いですが) の方で、場所を貸してくださる
soda:871> 方はいないでしょうか？
seirios:873> 大学とか研究機関が良いでしょうね。あとは、個人宅とか。
seirios:873> (今時は 64K 位なら結構もっている人居るでしょ？)
lfo:875> ポリシー的には問題ないです。
lfo:875> 外からだと SINET→TOPIC→ 経由になります。
lfo:875> 提供できそうな私物マシンもあるにはあるのですが、
lfo:875> SS2 とか、Sun3/80 とか、そんなんばっかりです。:-)
taca:876> 拙宅はOCNエコノミーです。地域的な関係か、今のところは殆んど
taca:876> 128kbps出てます。:-) 定常稼働のマシン(僕がささっとリブートも
taca:876> しない)もありますが、ディスクはあんまりあいてないです。
ayamura:879> 大学とかでもできないことはありません。今のところの
ayamura:879> 落ちまくりの NetBSD/sparc あたりになるでしょうが :)
ayamura:879> RingServer Project でやっていただくという手もあります。
h-masuda:880> うちもOCNエコノミーがあり、NetBSDな計算機(i386,pc98,alpha,
h-masuda:880> newsmips,pmax)がたむろしてますが、ちょっと遅いです(;_;)
4人のかたから、5つの代案が出ました。
＃個人的にはSINETは遠いのでって思って、tracerouteしたら結構近かった :-)
-- 引用したメールのmessage-id一覧
Message-Id: <199901172040.FAA16204@srapc342.sra.co.jp>
Message-Id: <19990120030101X.ura@yamato.ibm.com>
Message-Id: <199901191836.DAA02800@srapc342.sra.co.jp>
Message-Id: <19990120100221X.seirios@Matrix.IRI.Co.Jp>
Message-Id: <199901200204.LAA19721@dione.cec.co.jp>
Message-Id: <199901200313.MAA08587@ruri.iri.co.jp>
Message-Id: <199901200258.LAA07750@srapc342.sra.co.jp>
Message-Id: <19990120140622F.seirios@Matrix.IRI.Co.Jp>
Message-Id: <199901200703.QAA04395@edge.sky.yamashina.kyoto.jp>
Message-Id: <19990120170701M.h-masuda@ics.es.osaka-u.ac.jp>
Message-Id: <199901200629.PAA15389@sayori.hg.iwate-pu.ac.jp>
Message-ID: <86u2xm74xx.fsf@feed.rcn.med.keio.ac.jp>
Message-Id: <199901200520.OAA08250@srapc342.sra.co.jp>
抜けているのがあったら、ごめんなさい。
--
ura