議論/成果を取り込もう

Top / 議論 / 成果を取り込もう

このページは何か？ (by ひげぽん) †

開発者として参加してくださるみなさんの作ったものがきちんとMonaに取り込まれるようにするために、どのような体制が必要かを考えるページです。
例えば、「成果が取り込まれていない通報所」みたいな場所を用意してそこで指摘されたものの取り込みを検討するとか。（あくまでも例です。他に良い方法があったらご意見下さい）

↑

コメント †

最新の1000件を表示しています。コメントページを参照

お名前:

Gakuさんの提案がとても良いと思いましたので、ひげぽん案をまとめました。議論/成果を取り込もう/案のまとめ -- ひげぽん 2006-10-05 (木) 00:23:24
もし以下で書いたような体制に移行するのであれば、0.2.5や全部入りの整備は私がやっても構いません。そうすればひげぽんさんにとっては今まで通り何も流儀を変えずにtrunkを心行くまでいじっていただいて、何か負担が増えるということは何もありません。そしてstableが外部アプリ開発者の受け皿になるという体制になっていくのではないでしょうか。そして私もコアがどうとかツリーがどうとかあれこれ口出しすることもなくなるでしょう。（ｗ -- Tino 2006-10-01 (日) 10:44:22
- お申し出ありがとうございます。他の人の意見をもう少し聞いてから結論を出させてください。 -- ひげぽん 2006-10-03 (火) 22:29:31
いずれにしてもユーザー環境に関しては私自身はコアから距離を置いて、外の人としていじるようなポジションを望んでいるということです。自動化した全部入り構想というのもその一環です。Linuxでのカーネルとディストリビューションと同じように独立して進めるというのも一つの考え方ですが、今の規模でそのように壁を作ってしまうと実質フォークになってしまって逆に混乱を招くという懸念があるので、仮に進めるとしても公式なものとしてやらなければ意味がないと考えています。つまり公式にstable-releaseとtrunkを分離した体制にしましょうということです。繰り返しますがアプリが10倍、100倍と指数関数的に増大しても対応できる体制をそろそろ考えましょうということです。 -- Tino 2006-10-01 (日) 10:18:40
- そうなるとバージョン番号のαやβの意味合いも変わってきます。もともとアプリ込みでバージョンを付けて配布していたのは、小規模な全部入り構想であると解釈できます。特に旧ツリー。それを分離してstableを外部向けに用意するのであれば、カーネル（というかコア）にαとかβとか付けるのはあまり意味がないので、完成度に関係なく0.3.0, 0.3.1のようにする方が良いでしょう。trunkからstableにバックポートすることを考えれば、Linuxのようにマイナーバージョンの偶数はstableで奇数がtrunkという付け方をすると合理的だと思います。 -- Tino 2006-10-01 (日) 10:27:01
- 今ちょうど0.3系で奇数なので、Linux流に移行するにはちょうど良い時期かもしれません。stableを別に用意するのであれば、0.3系から色々とバックポートして、0.2.5として整備する必要があるでしょう。このようにすればなるべく早く0.3.0の正式リリースを出さないといけないという強迫観念からも解放されるかもしれません。意識する・しないに関わらず、バージョンにαとか付いていれば仮のものというイメージが付いて回りますから。 -- Tino 2006-10-01 (日) 10:35:18
下に書いたように私は外部の人には変化のない固定化されたリリースを前提にするべきであるという立場ですが、ひげぽんさんの立場に立ってtrunkでの動作確認の便宜を考えてみます。いくらポリシーが「Monaはなるべく過去の負の遺産を引き継がないように努めています。」で、Mona自身が内包する遺産までリストラ対象になり得ると言っても、やはり一定の規模での動作確認は必要なので、典型的な動作をするものは常に追随させておく必要性があります。この意味でbaysideさんのおっしゃる「厳選」は理解できます。しかしこれは「全部入り」とは相容れないと考えます。今の規模なら努力でどうにかなるかもしれませんが、今後どんどんアプリが増えて、全部入りの規模が10倍、100倍と指数関数的に増えていけば、絶対に手に負えなくなるのは明白だからです。 -- Tino 2006-10-01 (日) 09:49:17
- そのためリリースを前提とした外の人向けの全部入り環境と、trunkを前提にした中の人向けの厳選環境とを、同列に扱うこと自体無理なのではないかと考えています。この辺の切り分けを意識して、私の今のポジションは完全に中の人にならずに、敢えて外の人として振舞っています（片足を突っ込んだような状態ではありますが）。 -- Tino 2006-10-01 (日) 09:52:55
- たとえばX11の管理方針を見ると、contribとして収録されているのは完全に枯れ切ったものばかりです。Monaのcontribの考え方も、そのように限定的に考えるのが、現実的ではないかということです。つまり現状コアとcontribとが分離されていますが、contribは準コア的な位置付けにして、全部入りのような構想は外に出してしまうべきではないかということです。もっともX11自体が枯れてコアAPIの非互換拡張をやりまくるような段階ではないので、その辺はMonaと違いますが。 -- Tino 2006-10-01 (日) 09:59:13
- そういう考え方をすると、結局旧ツリーのような構成が落とし所ではないかという気がしてきます。もともと新ツリーの叩き台を示したのは（七誌ですがあれも私です）、互換性など切り離して好きに開発できる最低限のものを、独立的に扱うことを前提にしていました。つまりフラットで独立的であることに主眼があったので、それを中途半端にツリー化してしまうのなら、旧ツリーから余分なものを削除するのと同じで、構成を変更する意味合いが薄いという印象を持っています。当時は色々とあって「もう二度とMonaには関わらない」と思っていたので、ツリー移行時の議論から抜けてしまったことを申し訳なく思っています。 -- Tino 2006-10-01 (日) 10:05:53
- 個人的な経験ですが「今後どんどんアプリが増えて、全部入りの規模が10倍、100倍と指数関数的に増えていけば、絶対に手に負えなくなるのは明白だからです」は困ったときに考えれば良いという法則の方がうまくいくような気がします。今の規模が大きくなったときにという想定が、何か月，何年後を想定しているかにも寄りますけども。Gakuさん、shadowさんあたりの意見も聞きたい所です． -- ひげぽん 2006-10-03 (火) 22:28:37
- 現時点で既に取り込みのオーバーヘッドが大きく取り込みきれていないのに、根性でカバーしようとしたり、まだいないメンテナに頼ったりしようとしているのは、充分に「困ったとき」だと感じます。そして「取り込み」という敷居はソフトの増加速度にも影響します。増えたら困るからブレーキを掛けるというなら理解できますが。 -- Tino 2006-10-04 (水) 00:16:01
- 上の意見には同意です。だからといってさらに新しく全部入りと作ろうとするのは、また負担が増えることになるので、同意できないです。旧ツリー -> 新ツリー、sf.jp -> sf.net の移行のための作業は見た目よりずっと大変で、この繰り返しははっきりってうんざりです。最近ギャラリーの反応が少ないのも、ついていけないという理由もあるのだと思います。極論をいえば、旧Monaツリーにバックポートしてメンテしていくほうが、旧来の開発者にとってはとっつきやすいかもしれません。 -- bayside 2006-10-04 (水) 00:41:43
- コメントのやり取りに埋もれた案を見て判断するには大きい話題だと思いました。Tinoさん案と、ひげぽんがこーしたいと思ってるイメージ、をそれぞれページに書き出してみません？それから再度、意見を求めても遅くないように思います。 -- Gaku 2006-10-04 (水) 02:39:22
自動で取り込むことには懐疑的です。contrib に入れるには、やはりある一定のクオリティがあるものに厳選したいです。旧ツリーにあるアプリで MonaForms 用が少ないのは自分の力量不足です。ただデグレード防止のために contrib は全部入りという考え方には賛成です。core 開発者も多少は contrib に気を配ってもらう（コンパイルエラーがおきない程度）だけでも一定の品質は保持できると思います。いわばアプリがテストコードになっているわけで。 -- bayside 2006-09-28 (木) 02:40:53
- contrib の動作確認はテストチームの仕事です。といってもいまはそんな人はいないので、自分がリリース担当として、contrib に入れた全アプリの動作確認は一応行っています。 -- bayside 2006-09-28 (木) 02:43:13
- ツリーと切り離した状態でのサードパーティーのソースの扱い方に標準仕様がなく、またツリーに組み込んだときの流儀は切り離した状態で使えないため、サードパーティーとツリーとの間に壁があるというのが、問題の本質だと考えています。私が個々はバラバラというか独立的な状態が望ましいと考えているのはそれが理由です。 -- Tino 2006-09-28 (木) 11:03:37
もちろんその前提は理解しています。ただ一発目は力わざでがーっとやるのが現実解だと思っていて、それに賛同する誰かが手伝ってくれたらうれしいなという話でした。 -- ひげぽん 2006-09-26 (火) 20:42:57
- （ageました）収録のシステムを差し替える（自動化等）と収録物が作り直しになって、力技でやったことが無駄になりますよ。旧ツリーから新ツリーに移行し切れていないものとかあるじゃないですか。それを繰り返すことを懸念しているのです。ですからシステムを差し替えることを視野に入れたら、無駄になるかもしれない大作業をやることには消極的にならざるを得ません。 -- Tino 2006-09-27 (水) 12:32:49
- まず私の認識として、現状のSVNベースのcontrib管理システムは敷居が高すぎる、というのが前提にあります。baysideさんが非常に苦労して構築されたと認識していますが、それを永続するのは負担が多過ぎるという印象です。そのため現時点で取り込みきれていないものを現在の体制に組み込むことには、残念ながら前向きになれないと感じています。 -- Tino 2006-09-27 (水) 13:37:55
- ぶっちゃけ私個人の意見として、CVSやSVNは敷居が高過ぎるので、どうしても自分の手元で神経質に管理したいという事情がない限り、もっと大らかにやった方が良いのではないかと考えています。ここではcontribのことを想定しています。カーネルやファイルサーバーは実質ひげぽんさんの個人管理なので、他人がとやかく言うことではないという認識です。 -- Tino 2006-09-27 (水) 13:41:00
- 永続性やCVS/SVN敷居が高いというのは理解できます。私が気にしているのは Mona のAPIがまだきちんとfixしていなくて流動的である点です。例えばつい最近もファイルAPIやDMAのAPIに変更があり、contribをgrepして修正を施しました。このように動くことが維持されるべき contrib が手元で簡単に管理できる必要を感じています。なので contrib が全部入りになる事を僕は望んでいます。APIが変わって何かが動かなくなるというのは完全に防ぐことは無理ですが、contrib が手元にあり簡単にビルドを試す環境があれば、APIを作る側も多少 contrib を気に留めながら開発が出来ると思います。そもそもAPIが変更になって互換性がなくなるのが問題であるという意見もあるかもしれませんが、私は現時点ではむしろAPIを変更するのに心理的障壁が少ない方がMonaの開発にとっては良いと考えています。まとめると「 contrib が手元で簡単に管理できる」かつ「一般開発者は簡単に登録できる」を実現できると皆幸せになりそうです。 -- ひげぽん 2006-09-27 (水) 22:28:50
- 話がまったく噛み合っていませんが、その違いは、私がそもそも外部の人はリリースを使うべき（今だと0.2.2）だという認識だからでしょう。αとかでガンガン拡張するときに互換性を意識すること自体がおかしいと感じています。αの段階を引っ張って、新機能を使うには追随しないといけないような状態になっていること自体、ちょっとどうかと感じているということです。 -- Tino 2006-09-28 (木) 09:03:20
- 外部の人はリリースを使うべきだという一般論は理解できます。御指摘の通りMonaはそのやりかたに則っていないのが原因でしょう。 -- ひげぽん 2006-10-03 (火) 22:20:09
ページタイトルとはちと違う話ですけど、成果を無駄にしないために再利用可能である、って事は重要です。なるべく使いまわせるインタフェースであれば、そのインタフェースに則った部品は再利用できます。つまり、だれかの書いた成果が無駄にならないってことです。また、だれかがインタフェースに合わせて書いてくれさえすれば自動的に成果を取り込めるって事です。てな訳でデザインのページに話題をつなげます。 -- Gaku 2006-09-27 (水) 00:38:54
- で「成果の取り込み」です。こういった体制を維持するのはそれなりに大変でしょう。大変な事を大変な思いをして維持するのは良い状態でないと思います。「取り込みをする」なんて事をせずに「勝手に取り込まれている」ようなインタフェースが公開できてる、事のがよほど良いです。そんな風になったら良いな、という話です。 -- Gaku 2006-09-27 (水) 00:43:37
  - 同感です。私がぼんやり考えていたことと方向性は同じではないかと思います。 -- Tino 2006-09-27 (水) 12:34:55
- インターフェースの固定には一度作って壊すが必要であると僕は思っていて、ファイル系は何度か作りなおしたので大分固定されてきたように思えます。残るインターフェースはMonAPIかな。（ちと広いか） -- ひげぽん 2006-09-27 (水) 22:31:06
  - 私が想定していたのはAPIという意味のインターフェースではなく、自動的に処理されるためのファイルの置き方のようなものをイメージしていました。 -- Tino 2006-09-28 (木) 09:00:45
マジレスすると、一度ローカルに保存して翌日読みかえすのはどうでしょう。隠居よりは大分前向き。僕もここへの書き込みの文章を寝かせるときがありますよ。＜余談 -- ひげぽん 2006-09-26 (火) 20:42:36
- これと同じことを昔私から書いたと思うので、逆に言われると奇妙です。で、数日寝かせると、言わなくてもいいやということになって、ますます隠居が加速しますよ。 -- Tino 2006-09-27 (水) 12:34:00
- で結局、私にガンガン書かせようとするなら、「お説教なんてとんでもない。とても役に立っています。」程度におだてておくのが上手な方法ですよ。 -- Tino 2006-09-28 (木) 09:05:09
これは構想だけですぐにやることは出来ませんが：過去のものは仕方ないとして、将来的にも延々と「成果を取り込む」という手順を続けるのは現実的ではない気がします。かと言ってメンテナを募集するというのはもっと現実的ではないでしょう。つまり「取り込む」ということ自体が壁になっています。この対案として、Wikiに特定の方法で置いておくだけで取り込まれるような仕組みが必要ではないかと考えています。これは性善説的な観点に基づくものですが、もちろん悪戯の懸念はあります。今はそこまで煮詰めていませんし議論する余力もないのでとりあえずメモとして書きました。 -- Tino 2006-09-26 (火) 00:07:07
- 今までサボっていた分はごめんなさい + 取り込むことを検討すると仮定します。「延々と成果を取り込む」ことが現実的でないの話ですが、がんばれるまではがんばるってのはどうですかね。多くても月に２本くらいの取り込みとかならこなせそうですし、こなしているうちにうまい方法を思いつくかも。 -- ひげぽん 2006-09-26 (火) 00:24:47
- 私が書いたのはただの妄想みたいなものなので、現実的には、ひげぽんさんがおっしゃっておられるような「がんばれるまではがんばる」しかないでしょう。先日話題に出たgentooの人が、膨大なパッケージに少人数で対処するコツは「自動化」だというようなことを書いておられました。私が考えているのも基本的にはその方向です。イメージとしてはSVNの代わりにWikiを使うようなものです。履歴管理はリリースごと（あるいは定期的）に退避させておけば、実用上充分ではないかと考えています。 -- Tino 2006-09-26 (火) 00:29:24
- 確かにWikiに添付すると勝手に解凍して最新版カーネルでビルドする。エラーがでたらエラーページに詳細がでる。みたいなのはありですね。 -- ひげぽん 2006-09-26 (火) 00:36:42
- それは面白いし、かなり現実味のあるアイデアですね。ひげぽんさんがEmacsでのビルドで取り組んでおられるのと同じように、自動化で手間を減らすという方向性を意識するのは大事なことでしょう。と、いつものごとくお説教で逃げる。（ｗ -- Tino 2006-09-26 (火) 01:00:36
  - 【余談】数日後に自分の書き込みを見ると、酔っ払ったときにやたらとお説教してくるおっさんにしか見えなくて、その度に隠居しなくちゃいけないという感を強くします。自分が手を出す覚悟を決めたときしか長文は書かないようにはしていますが・・・。 -- Tino 2006-09-26 (火) 01:02:20
  - そうですね。面白いと思いますがすぐにやろうという感じでもないですね。 -- ひげぽん 2006-09-26 (火) 20:42:24
私が議論/Mona全体図の提案で「くろーら」と名乗ってWikiの走査をしていたのは、過去の成果を漏らさない完全版全部入りを作ろうという意図でした。走査も完全版構想も、まったく時間がなくて取り組めそうもありませんが、とりあえず現時点でリストアップしたアプリケーション一覧をまとめておきます。⇒アプリケーション一覧 -- Tino 2006-09-25 (月) 23:39:20
- ありがとうございます。取り込み済か、取り込むべきかを整理してがーっと取り込むのもありかと思いました。僕一人でやるのはしんどうそうなので手伝ってくれる方がいたらですけど． -- ひげぽん 2006-09-26 (火) 00:26:45
- 私がイメージしていたのは、1.走査、2.自動化した管理方法の確立、という手順を追って、完全版を作るという回りくどい方法です。一時的に力技で対処することは可能ですし、走査自体がその力技なのですが、それを永続させるのは無理な相談だというのが前提です。 -- Tino 2006-09-26 (火) 00:30:55

このページは何か？ (by ひげぽん) †

コメント †

MENU

リンク

最新の20件

最新の20件