Hyper Operating System(ITRON仕様OS)

Fork

Ryuzです。

＞ ・HOSエミュレータ

　えっとOSのエミュってどういうものなんでしょう？
　プロセッサのエミュがあれば動いちゃうのでいまいち
ピンと来てないのですが詳細希望です。


＞ ・ビジュアルデバッガ（できるか？）

これは個人的には期待しまくりです。
　TCB内容をアクセスできるとめっちゃ便利ですもんね。
　市販OSに対応したデバッガはいくつかありますが、
フリーだとしばしばこれはがネックで。

　とりあえずポリシーには同意いただけたようでう
ですので、私の方で登録処理しますね。

なんか、AM1時を回っているような。。。。
プロジェクト管理って、大変ですよね。
（会社でも、本当は、管理する側に回らないといけない身分なのですがねえ。ほんと、まだまだ作っているし、、、）
今後ともよろしく御願いいたします。

メンバーとcommit権限って不可分だったような...

こんにちは、henohenoです。


hosのデベロッパーではありませんが、縁あって
SFに移行した折から開発チームに名を連ねております。
(現在は主にpukiwikiプロジェクトのメンテナンスを行っています)

オープンソースプロジェクトのメンバーについて、
外部メンバーとしてのコメントを送ります。
基本的な事が中心ですが、確認の意味を込めて (^^;


0. 受け入れをスムーズにしないと話が始まらない
　興味がある人が現れたり、問題が上がった時にタイムリーに対応できないと、話は盛り下がります。とはいっても既存メンバーの体力や状況に依存しているので、体を壊さない程度にしなければなりません。

1. 行動で語らないと話が先に進まない
　この場合の行動とは、質問やアイデアの数ではなく、誰も見ていなかった役に立つ切り口や、現実的な改善策や、実際に既存の開発者を動かすような、意味のあるパッチ(の数やボリューム)です。
　役割や権限は一緒になって実績を重ねるうちに、必要にせまられて変化します。(必要にせまられる主体は既存のメンバーです)

2. 権限を持つ者が複数人いないと突然止まりかねない
　(特に管理者権限について)複数人いるべき理由は冗長性と、死亡時などのトラブル回避です。初めから息の長いプロジェクトだと思った方が良いでしょう。

3. 権限を持つ者は必要最小人数でないと混乱する
　行動しない、あるいは実績のメンバー(複数)に権限を配りすぎると、既存のメンバーは不安になります。たとえCVSリポジトリがユーザーを識別するとはいっても、ケアレスミスや連絡の行き違いで混乱に陥ることがあります。

4. 役割(作業領域)ごとに担当が分かれないと並行作業が進まない
　ソース上のブランチごと、意味のあるディレクトリごと、あるいはWebスペースのコンテンツごと(今ならWikiは誰が管理するか？掲示板を立てる時は？etc) に、主な作業者を決めた方が良いです。
　担当はプロジェクトへの貢献度が最も高まるであろう、かつ各人のモチベーションが最も高まるであろうところ、つまりその人が今まで実際に修正したことのあるファイルやディレクトリが良いでしょう。

5. 過程を明確にしてもらわないと問題を共有できない
　CVSリポジトリのコミットログ、ChangeLog、(もし用意するのであれば)開発日記やブログなどで、作業したメンバーはその過程や理由を明確に残すべきです。「なぜこうなったのか」という情報が発散したり失われたりしないように、きちんと残す必要があります。


こんな所でしょうか (^^;
突発的に書いたので妙なところもあると思いますが、
その際はコメントいただければ幸いです。