wiki:MonthlyIrcMeeting/20091205

Version 14 (modified by munepi, 14 years ago) (diff)

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

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

日時

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

参加者

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

議題

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

議事録

  • 「公式のリポジトリのみで運用可能にします」は当たり前なことなのでは?→削除
    • 表現に問題はある。
      • 「運用可能」ではなく「運用管理」でよいのでは?
    • 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に)「同一目的のためのパッケージを複数収録しない」というポリシー』について
    • 『メインパッケージは1用途1パッケージで構成します』の表現の方がよいのでは?
    • 『メインパッケージを厳選します』ぐらいが妥当。
  • 次期 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 する
          • Pin: release a=stable-proposed-updates で Pin-Priority: -1 などにする