アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
わけわからん (スコア:0)
和ジラと洋ジラってどう違うのか分からずに混乱しています。
Re:わけわからん (スコア:0)
和ジラのサイト見たら、載ってました。すみません。
Re:わけわからん (スコア:2, 興味深い)
私はこうしたプロジェクトを立てる前に、どうやったら mozilla プロジェクトのほうでレビューを早く進ませるかを考えるべきだと思います。
前提をご理解ください (スコア:1, 参考になる)
バグレポート個々をそれぞれ追っかけてみてください。
>私はこうしたプロジェクトを立てる前に、どうやったら mozilla
>プロジェクトのほうでレビューを早く進ませるかを考えるべきだと思います。
という話は、それからにしましょう。
でないと、異なる前提で論を交わすだけになりますから。
ちなみに、
.orgのレビューワが足りないなら自分たちで..って話は難しいです。
かなりの広範囲な知識が必要ですし、現レビューワ達からの
ある種の信頼を得るだけの実績が必要ですから。
担当者も似たような理由で難しいです。他プラットフォームや
国際化の知識が不足したエンジニアのおかげで新たなバグが
入ることがしばしばある現状、それを更に促進するのは危険ですから。
Re:前提をご理解ください (スコア:1)
気になるのは、そんなオープンソースプロジェクトに、一体どういうモチベーションでコードの解析、修正に取り組んでいるのでしょうか。
(ムリしてやることでは決して無いので、フルタイムで mozilla に取り組んでる人にまかせちゃっていいんじゃないかと・・・。バグレポートだけしっかりやってあげれば)
Re:前提をご理解ください (スコア:1, 参考になる)
>プロジェクトは面白みがないですよね。修正したコードが長い長い手続きの末
>ようやく取り込まれるってんじゃ、少なくともプログラミングの楽しみは
>味わえないのではないかと思います。
そう思う人もいれば、そうは思わない人もいるんじゃないかと。
(当然なことですが)
数年前の mozilla.org に関わっていたエンジニアは、まず実装してテストしてみようという向きがどこかありました。 素早く実装し素早くテストし、その評価で持って採用 or 書き直しに取り組むというのは一つの良い手なのですが、(それが原因の一つなのかどうかはさておき)バグは修正されるけど同じくらい新しいバグが増えたり、以前に修正したバグが再発する事がたびたびありました。
そこである時点から、レビューというステップを強化しました。レビューワのほかにスーパーレビューワという存在を設け、それぞれの評価を得てやっとコードを採用するようになりました。(部位によって厳格さに違いはあります)
http://jt.mozilla.gr.jp/hacking/reviewers.html
http://www.mozilla.org/hacking/reviewers.html
そのため、レビュー待ちだったりする場面が以前より増えています。
でもしかし、多くの人はそれが必要なステップだと考えているようです。
(大きな反対意見をあまり見てないので)
>気になるのは、そんなオープンソースプロジェクトに、一体どういうモチ
>ベーションでコードの解析、修正に取り組んでいるのでしょうか。
それが楽しいからとか、自分が使いたいソフトウェアの質を高めたいとか、いま困っているバグを自分で修正したいとか、ふつーの理由じゃないかと。
まぁ中には作業速度が遅くなったがために関わるのを辞めた人もいるかもしれません。広義で言えば jwz はそうかも。
で、
>(ムリしてやることでは決して無いので、フルタイムで mozilla に取り
>組んでる人にまかせちゃっていいんじゃないかと・・・。バグレポートだけ
>しっかりやってあげれば)
まさに現状、そういう状況なんですよね。レポートやパッチの
質を高めるためにパッチテストの和ジラが生まれた訳で。
そこで、
>>私はこうしたプロジェクトを立てる前に、どうやったら mozilla
>>プロジェクトのほうでレビューを早く進ませるかを考えるべきだと思います。
と意見が出たので色々と私も意見を述べたり知っている情報を書いたりしている訳で。
ね。