Changes between Version 14 and Version 15 of MonthlyIrcMeeting/20091205


Ignore:
Timestamp:
2009/12/28 07:56:28 (17 years ago)
Author:
munepi
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • MonthlyIrcMeeting/20091205

    v14 v15  
    4141== 議事録 == 
    4242 
    43  * 1. Vine Linuxの方針について http://trac.vinelinux.org/wiki/VineLinuxPolicy 
    44    * 基本的にはこれまでのもやもやっとした方針を明文化する 
     43=== 1. Vine Linuxの方針について http://trac.vinelinux.org/wiki/VineLinuxPolicy === 
     44 * 基本的にはこれまでのもやもやっとした方針を明文化する 
    4545 
    46    * 「公式のリポジトリのみで運用可能にします」は当たり前なことなのでは？→削除 
    47       * 表現に問題はある。 
    48         * 「運用可能」ではなく「運用管理」でよいのでは？ 
    49       * self-build, install-assist は外部の「リポジトリ」ではないが、外部からひっぱってきている。しかしながら、公式リポジトリの non-free カテゴリで依存の解決、調整を図って、検証、テストしている。 
    50       * non-free カテゴリは、debian-multimedia や atrpms/freshrpms/... みたいなのとは違う 
     46 * 「公式のリポジトリのみで運用可能にします」は当たり前なことなのでは？→削除 
     47    * 表現に問題はある。 
     48      * 「運用可能」ではなく「運用管理」でよいのでは？ 
     49    * self-build, install-assist は外部の「リポジトリ」ではないが、外部からひっぱってきている。しかしながら、公式リポジトリの non-free カテゴリで依存の解決、調整を図って、検証、テストしている。 
     50    * non-free カテゴリは、debian-multimedia や atrpms/freshrpms/... みたいなのとは違う 
    5151 
    52    * 「リリース間隔をハッキリさせる」ことについて 
    53      * リリース日を決めるのではなく、feature freeze 日を決めるとよいのでは？ 
    54        * Feature Freaze から n 日間バグが出なければ、次のステージへ 
    55      * マイナーバージョンアップの回数を増やしてもよいのでは？ 
    56        * proposed-update ができたことにより、マイナーバージョンアップのタイミングが図りやりやすくなった。 
    57      * QA チームみたいなのも必要かもしれない 
    58        * ドキュメントチームの拡充、活動の宣伝？ 
     52 * 「リリース間隔をハッキリさせる」ことについて 
     53   * リリース日を決めるのではなく、feature freeze 日を決めるとよいのでは？ 
     54     * Feature Freaze から n 日間バグが出なければ、次のステージへ 
     55   * マイナーバージョンアップの回数を増やしてもよいのでは？ 
     56     * proposed-update ができたことにより、マイナーバージョンアップのタイミングが図りやりやすくなった。 
     57   * QA チームみたいなのも必要かもしれない 
     58     * ドキュメントチームの拡充、活動の宣伝？ 
    5959 
    60    * 「Vine Linuxのターゲットユーザ」について 
    61      * 個人、学校、SOHO あたりがメイン。 
    62      * 個人の中でもいわゆる early adopter（＝最新を追っかける人）は対象ではない 
    63        * サクサク入れ替えることを気にしない/むしろやりたい人は…、ぜひとも VineSeed で活動して！ 
    64          * （VineSeed については、特別ポリシーには記述しないが、）VineSeed は、結構自由にいじれて、作ったパッケージをringサーバでバックアップできる、自分が作ったものを、Vine Linux に導入できるという利点がある。 
    65      * Linuxを常用OSとして使用したい個人・SOHO 
    66      * 学習環境として構築したい学校 
     60 * 「Vine Linuxのターゲットユーザ」について 
     61   * 個人、学校、SOHO あたりがメイン。 
     62   * 個人の中でもいわゆる early adopter（＝最新を追っかける人）は対象ではない 
     63     * サクサク入れ替えることを気にしない/むしろやりたい人は…、ぜひとも VineSeed で活動して！ 
     64       * （VineSeed については、特別ポリシーには記述しないが、）VineSeed は、結構自由にいじれて、作ったパッケージをringサーバでバックアップできる、自分が作ったものを、Vine Linux に導入できるという利点がある。 
     65   * Linuxを常用OSとして使用したい個人・SOHO 
     66   * 学習環境として構築したい学校 
    6767 
    68    * 「軽量・高速化」の話 
    69      * shaolin さんの記事の『軽量・コンパクトを狙ったパッケージ選定』を元に再構成する 
    70      * どこまで軽量なのを求めるのか？ 
    71        * 『アプリケーションの便利さ・快適さと動作速度のバランスを念頭に置いて』とあるように、何が何でも軽量化という話ではない 
    72        * 軽量にするというよりは、重量級にはしない。実際に、相対的に軽くなっている。 
    73        * ネットブックは、アプリケーションをコンパイルしなければ、大抵のアプリケーションはある程度快適に動作する。 
    74        * プラットフォーム（kernel、バックグラウンドサービス等）が重いのとアプリが重いのは別問題だけど、なぜか Linux では一緒にされがち。 
    75          * 異なるちがうプラットフォーム上でビルドすると、違うものができあがる (ものもある) からではないか。 
    76        * ネットブックを軽量化の対象とすることついては、検討する。 
     68 * 「軽量・高速化」の話 
     69   * shaolin さんの記事の『軽量・コンパクトを狙ったパッケージ選定』を元に再構成する 
     70   * どこまで軽量なのを求めるのか？ 
     71     * 『アプリケーションの便利さ・快適さと動作速度のバランスを念頭に置いて』とあるように、何が何でも軽量化という話ではない 
     72     * 軽量にするというよりは、重量級にはしない。実際に、相対的に軽くなっている。 
     73     * ネットブックは、アプリケーションをコンパイルしなければ、大抵のアプリケーションはある程度快適に動作する。 
     74     * プラットフォーム（kernel、バックグラウンドサービス等）が重いのとアプリが重いのは別問題だけど、なぜか Linux では一緒にされがち。 
     75       * 異なるちがうプラットフォーム上でビルドすると、違うものができあがる (ものもある) からではないか。 
     76     * ネットブックを軽量化の対象とすることついては、検討する。 
    7777 
    78    * 『(mainに)「同一目的のためのパッケージを複数収録しない」というポリシー』について 
    79      * 『メインパッケージは１用途１パッケージで構成します』の表現の方がよいのでは？ 
    80      * 『メインパッケージを厳選します』ぐらいが妥当。 
     78 * 『(mainに)「同一目的のためのパッケージを複数収録しない」というポリシー』について 
     79   * 『メインパッケージは１用途１パッケージで構成します』の表現の方がよいのでは？ 
     80   * 『メインパッケージを厳選します』ぐらいが妥当。 
    8181 
    82  * 次期 BTS 候補 mantis について 
    83    * tomopさんの mantis テスト環境から patched source を頂く。 
    84    * 現 BTS のデータからどうやって import するか 
    85      * DB を MySQL にする方向で検討中 
    86      * 方向性としては、スクリプト等でimportする、あるいは、しばらく影舞をRead Onlyで運用して必要なものを手動でimportするというのを決める 
    87        * データ移行スクリプトは、tomop さんが作成済み。 
    88      * mantisのテーブル構成 http://bacons.ddo.jp/wiki/mantis/misc/db/1.2.0 
    89    * Trac のチケットは、内部のIssue管理用として利用する。 
     82=== 次期 BTS 候補 mantis について === 
     83 * tomopさんの mantis テスト環境から patched source を頂く。 
     84 * 現 BTS のデータからどうやって import するか 
     85   * DB を MySQL にする方向で検討中 
     86   * 方向性としては、スクリプト等でimportする、あるいは、しばらく影舞をRead Onlyで運用して必要なものを手動でimportするというのを決める 
     87     * データ移行スクリプトは、tomop さんが作成済み。 
     88   * mantisのテーブル構成 http://bacons.ddo.jp/wiki/mantis/misc/db/1.2.0 
     89 * Trac のチケットは、内部のIssue管理用として利用する。 
    9090 
    91  * Vine Linux 6.0 に向けて 
    92    * 当面の目標としては、細かい修正以外では toolchain を何とかして rebuild 一周する。 
     91=== Vine Linux 6.0 に向けて === 
     92 * 当面の目標としては、細かい修正以外では toolchain を何とかして rebuild 一周する。 
    9393 
    94  * 5.1 リリースパーティについて 
    95    * 担当：広報部長らしい。それで、多数賛成らしい。 
    96    * munepi さんが OSC2010 Tokyo/Spring を検討中らしい。 
     94=== 5.1 リリースパーティについて === 
     95 * 担当：広報部長らしい。それで、多数賛成らしい。 
     96 * munepi さんが OSC2010 Tokyo/Spring を検討中らしい。 
    9797 
    98  * proposed-updates について 
    99    * proposed-updates のテストフローが見えていないので、テストの処理フローをまとめたページが必要ではないか。 
    100      * 固定的なQAチームみたいのがないとなかなかテストが進まないのではないか 
    101      * apt-sourceslist-proposed-updates パッケージがすでにリポジトリに存在している 
    102      * vine-users ML にテストユーザを求める手もあり。 
    103      * BTS のタイトルに、[proposed-updates] を意識的に付ける 
    104        * ただし、Security Issueを含む場合は、書き方に気をつける必要がある。 
    105      * (core を除いて)テストに期限を設ける 
    106        * (core を除く) proposed-updates は1ヶ月経過したら、errata を発行する 
    107      * apt-line proposed-updates {on|off} を楽にできないか？ 
    108        * sources.list.available/ にいれて sources.list.d/ 内から symlink とかにする か 
    109        * pin する 
    110          * Pin: release a=stable-proposed-updates で Pin-Priority: -1 などにする 
     98=== proposed-updates について === 
     99 * proposed-updates のテストフローが見えていないので、テストの処理フローをまとめたページが必要ではないか。 
     100   * 固定的なQAチームみたいのがないとなかなかテストが進まないのではないか 
     101   * apt-sourceslist-proposed-updates パッケージがすでにリポジトリに存在している 
     102   * vine-users ML にテストユーザを求める手もあり。 
     103   * BTS のタイトルに、[proposed-updates] を意識的に付ける 
     104     * ただし、Security Issueを含む場合は、書き方に気をつける必要がある。 
     105   * (core を除いて)テストに期限を設ける 
     106     * (core を除く) proposed-updates は1ヶ月経過したら、errata を発行する 
     107   * apt-line proposed-updates {on|off} を楽にできないか？ 
     108     * sources.list.available/ にいれて sources.list.d/ 内から symlink とかにする か 
     109     * Pin: release a=stable-proposed-updates で Pin-Priority: -1 などにする