= 第18回 定例IRCミーティング =

== 日時 ==

 * 2009/12/05
 * 21:00-23:00

== 参加者 ==

 * daisuke
 * shaolin
 * yasumichi
 * tomop
 * inagaki
 * Takemikaduchi
 * munepi
 * harada
 * owa
 * iwaim

== 議題 ==

 * [wiki:VineLinuxPolicy Vine Linuxの方針]について
 * BTS の Mantis への移行をどうやって進めるか
 * 6.0 に向けた開発状況
  * TODO for 6.0 タスクの優先順位と担当者のリスト化
  * toolchain の更新
  * core feature/major component の選定
  * (参考) [wiki:Vine6/Roadmap Vine Linux 6 スケジュール]
 * 5.1 リリースパーティ (担当は?)
 * proposed-updates の package release 条件の検討
   * [wiki:maintenance/approval 承認プロセス（素案）]には、core/main の enhance update 相当の package を relase する条件として以下2つが記載されている
     * 複数の動作確認レポートを package release の条件とする[[br]]
       package 作成者は人数にカウントしない
     * 全 arch の動作確認レポートを package release の条件とする 
   * しかし実際には動作確認レポートがほとんど登録されておらず、errata 発行が滞り気味
   * どこまでテストすべきかの議論は必要なものの、処理を促進する為に[[br]]
     「 proposed-updated に put されてから(例えば)1ヶ月間経過したら、不具合報告が無い限り release する」[[br]]
     といった条件を追加できないか検討したい。

== 議事録 ==

=== 1. Vine Linuxの方針について http://trac.vinelinux.org/wiki/VineLinuxPolicy ===
 * 基本的にはこれまでのもやもやっとした方針を明文化する

 * 「公式のリポジトリのみで運用可能にします」は当たり前なことなのでは？→削除
    * 表現に問題はある。
      * 「運用可能」ではなく「運用管理」でよいのでは？
    * self-build, install-assist は外部の「リポジトリ」ではないが、外部からひっぱってきている。しかしながら、公式リポジトリの non-free カテゴリで依存の解決、調整を図って、検証、テストしている。
    * non-free カテゴリは、debian-multimedia や atrpms/freshrpms/... みたいなのとは違う

 * 「リリース間隔をハッキリさせる」ことについて
   * リリース日を決めるのではなく、feature freeze 日を決めるとよいのでは？
     * Feature Freaze から n 日間バグが出なければ、次のステージへ
   * マイナーバージョンアップの回数を増やしてもよいのでは？
     * proposed-update ができたことにより、マイナーバージョンアップのタイミングが図りやりやすくなった。
   * QA チームみたいなのも必要かもしれない
     * ドキュメントチームの拡充、活動の宣伝？

 * 「Vine Linuxのターゲットユーザ」について
   * 個人、学校、SOHO あたりがメイン。
   * 個人の中でもいわゆる early adopter（＝最新を追っかける人）は対象ではない
     * サクサク入れ替えることを気にしない/むしろやりたい人は…、ぜひとも VineSeed で活動して！
       * （VineSeed については、特別ポリシーには記述しないが、）VineSeed は、結構自由にいじれて、作ったパッケージをringサーバでバックアップできる、自分が作ったものを、Vine Linux に導入できるという利点がある。
   * Linuxを常用OSとして使用したい個人・SOHO
   * 学習環境として構築したい学校

 * 「軽量・高速化」の話
   * shaolin さんの記事の『軽量・コンパクトを狙ったパッケージ選定』を元に再構成する
   * どこまで軽量なのを求めるのか？
     * 『アプリケーションの便利さ・快適さと動作速度のバランスを念頭に置いて』とあるように、何が何でも軽量化という話ではない
     * 軽量にするというよりは、重量級にはしない。実際に、相対的に軽くなっている。
     * ネットブックは、アプリケーションをコンパイルしなければ、大抵のアプリケーションはある程度快適に動作する。
     * プラットフォーム（kernel、バックグラウンドサービス等）が重いのとアプリが重いのは別問題だけど、なぜか Linux では一緒にされがち。
       * 異なるちがうプラットフォーム上でビルドすると、違うものができあがる (ものもある) からではないか。
     * ネットブックを軽量化の対象とすることついては、検討する。

 * 『(mainに)「同一目的のためのパッケージを複数収録しない」というポリシー』について
   * 『メインパッケージは１用途１パッケージで構成します』の表現の方がよいのでは？
   * 『メインパッケージを厳選します』ぐらいが妥当。

=== 次期 BTS 候補 mantis について ===
 * tomopさんの mantis テスト環境から patched source を頂く。
 * 現 BTS のデータからどうやって import するか
   * DB を MySQL にする方向で検討中
   * 方向性としては、スクリプト等でimportする、あるいは、しばらく影舞をRead Onlyで運用して必要なものを手動でimportするというのを決める
     * データ移行スクリプトは、tomop さんが作成済み。
   * mantisのテーブル構成 http://bacons.ddo.jp/wiki/mantis/misc/db/1.2.0
 * Trac のチケットは、内部のIssue管理用として利用する。

=== Vine Linux 6.0 に向けて ===
 * 当面の目標としては、細かい修正以外では toolchain を何とかして rebuild 一周する。

=== 5.1 リリースパーティについて ===
 * 担当：広報部長らしい。それで、多数賛成らしい。
 * munepi さんが OSC2010 Tokyo/Spring を検討中らしい。

=== proposed-updates について ===
 * proposed-updates のテストフローが見えていないので、テストの処理フローをまとめたページが必要ではないか。
   * 固定的なQAチームみたいのがないとなかなかテストが進まないのではないか
   * apt-sourceslist-proposed-updates パッケージがすでにリポジトリに存在している
   * vine-users ML にテストユーザを求める手もあり。
   * BTS のタイトルに、[proposed-updates] を意識的に付ける
     * ただし、Security Issueを含む場合は、書き方に気をつける必要がある。
   * (core を除いて)テストに期限を設ける
     * (core を除く) proposed-updates は1ヶ月経過したら、errata を発行する
   * apt-line proposed-updates {on|off} を楽にできないか？
     * sources.list.available/ にいれて sources.list.d/ 内から symlink とかにする か
     * Pin: release a=stable-proposed-updates で Pin-Priority: -1 などにする