Changes between Version 13 and Version 14 of MonthlyIrcMeeting/20091205


Ignore:
Timestamp:
2009/12/28 07:53:49 (14 years ago)
Author:
munepi
Comment:

議事録を書き起こしました。

Legend:

Unmodified
Added
Removed
Modified
  • MonthlyIrcMeeting/20091205

    v13 v14  
    3838     「 proposed-updated に put されてから(例えば)1ヶ月間経過したら、不具合報告が無い限り release する」[[br]] 
    3939     といった条件を追加できないか検討したい。 
     40 
     41== 議事録 == 
     42 
     43 * 1. Vine Linuxの方針について http://trac.vinelinux.org/wiki/VineLinuxPolicy 
     44   * 基本的にはこれまでのもやもやっとした方針を明文化する 
     45 
     46   * 「公式のリポジトリのみで運用可能にします」は当たり前なことなのでは?→削除 
     47      * 表現に問題はある。 
     48        * 「運用可能」ではなく「運用管理」でよいのでは? 
     49      * self-build, install-assist は外部の「リポジトリ」ではないが、外部からひっぱってきている。しかしながら、公式リポジトリの non-free カテゴリで依存の解決、調整を図って、検証、テストしている。 
     50      * non-free カテゴリは、debian-multimedia や atrpms/freshrpms/... みたいなのとは違う 
     51 
     52   * 「リリース間隔をハッキリさせる」ことについて 
     53     * リリース日を決めるのではなく、feature freeze 日を決めるとよいのでは? 
     54       * Feature Freaze から n 日間バグが出なければ、次のステージへ 
     55     * マイナーバージョンアップの回数を増やしてもよいのでは? 
     56       * proposed-update ができたことにより、マイナーバージョンアップのタイミングが図りやりやすくなった。 
     57     * QA チームみたいなのも必要かもしれない 
     58       * ドキュメントチームの拡充、活動の宣伝? 
     59 
     60   * 「Vine Linuxのターゲットユーザ」について 
     61     * 個人、学校、SOHO あたりがメイン。 
     62     * 個人の中でもいわゆる early adopter(=最新を追っかける人)は対象ではない 
     63       * サクサク入れ替えることを気にしない/むしろやりたい人は…、ぜひとも VineSeed で活動して! 
     64         * (VineSeed については、特別ポリシーには記述しないが、)VineSeed は、結構自由にいじれて、作ったパッケージをringサーバでバックアップできる、自分が作ったものを、Vine Linux に導入できるという利点がある。 
     65     * Linuxを常用OSとして使用したい個人・SOHO 
     66     * 学習環境として構築したい学校 
     67 
     68   * 「軽量・高速化」の話 
     69     * shaolin さんの記事の『軽量・コンパクトを狙ったパッケージ選定』を元に再構成する 
     70     * どこまで軽量なのを求めるのか? 
     71       * 『アプリケーションの便利さ・快適さと動作速度のバランスを念頭に置いて』とあるように、何が何でも軽量化という話ではない 
     72       * 軽量にするというよりは、重量級にはしない。実際に、相対的に軽くなっている。 
     73       * ネットブックは、アプリケーションをコンパイルしなければ、大抵のアプリケーションはある程度快適に動作する。 
     74       * プラットフォーム(kernel、バックグラウンドサービス等)が重いのとアプリが重いのは別問題だけど、なぜか Linux では一緒にされがち。 
     75         * 異なるちがうプラットフォーム上でビルドすると、違うものができあがる (ものもある) からではないか。 
     76       * ネットブックを軽量化の対象とすることついては、検討する。 
     77 
     78   * 『(mainに)「同一目的のためのパッケージを複数収録しない」というポリシー』について 
     79     * 『メインパッケージは1用途1パッケージで構成します』の表現の方がよいのでは? 
     80     * 『メインパッケージを厳選します』ぐらいが妥当。 
     81 
     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管理用として利用する。 
     90 
     91 * Vine Linux 6.0 に向けて 
     92   * 当面の目標としては、細かい修正以外では toolchain を何とかして rebuild 一周する。 
     93 
     94 * 5.1 リリースパーティについて 
     95   * 担当:広報部長らしい。それで、多数賛成らしい。 
     96   * munepi さんが OSC2010 Tokyo/Spring を検討中らしい。 
     97 
     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 などにする