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/... みたいなのとは違う |
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 | * 学習環境として構築したい学校 |
68 | | * 「軽量・高速化」の話 |
69 | | * shaolin さんの記事の『軽量・コンパクトを狙ったパッケージ選定』を元に再構成する |
70 | | * どこまで軽量なのを求めるのか? |
71 | | * 『アプリケーションの便利さ・快適さと動作速度のバランスを念頭に置いて』とあるように、何が何でも軽量化という話ではない |
72 | | * 軽量にするというよりは、重量級にはしない。実際に、相対的に軽くなっている。 |
73 | | * ネットブックは、アプリケーションをコンパイルしなければ、大抵のアプリケーションはある程度快適に動作する。 |
74 | | * プラットフォーム(kernel、バックグラウンドサービス等)が重いのとアプリが重いのは別問題だけど、なぜか Linux では一緒にされがち。 |
75 | | * 異なるちがうプラットフォーム上でビルドすると、違うものができあがる (ものもある) からではないか。 |
76 | | * ネットブックを軽量化の対象とすることついては、検討する。 |
| 68 | * 「軽量・高速化」の話 |
| 69 | * shaolin さんの記事の『軽量・コンパクトを狙ったパッケージ選定』を元に再構成する |
| 70 | * どこまで軽量なのを求めるのか? |
| 71 | * 『アプリケーションの便利さ・快適さと動作速度のバランスを念頭に置いて』とあるように、何が何でも軽量化という話ではない |
| 72 | * 軽量にするというよりは、重量級にはしない。実際に、相対的に軽くなっている。 |
| 73 | * ネットブックは、アプリケーションをコンパイルしなければ、大抵のアプリケーションはある程度快適に動作する。 |
| 74 | * プラットフォーム(kernel、バックグラウンドサービス等)が重いのとアプリが重いのは別問題だけど、なぜか Linux では一緒にされがち。 |
| 75 | * 異なるちがうプラットフォーム上でビルドすると、違うものができあがる (ものもある) からではないか。 |
| 76 | * ネットブックを軽量化の対象とすることついては、検討する。 |
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管理用として利用する。 |
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 などにする |