OpenWrtのソースコード

こちらの記事もご覧ください: Adding a new device

OpenWrtプロジェクトのソースコードは、これまでに作成されたすべてのブランチとリリースを含むGitツリー内に保存されています。

すべてのレポジトリは以下のサイトで閲覧できます:

1. GitWeb - OpenWrtのマスターGitリポジトリ
2. GitHub - 継続的にアップデートされるGitWebのミラー

OpenWrtのすべての開発は、メインのGitリポジトリで行われており、HTTPおよびHTTPS経由でアクセス可能です:

git clone https://git.openwrt.org/openwrt/openwrt.git

このレポジトリのミラーはGitHubにも存在します:

git clone https://github.com/openwrt/openwrt.git

プロジェクトのgitレポジトリ内には以下のディレクトリがあります:

• /config : menuconfig用の設定ファイル
• /include : Makefileの設定ファイル
• /package : パッケージのMakefileと設定
• /scripts : ビルドプロセス全体で使用される様々なスクリプト
• /target : imagebuilder, カーネル, SDK, buildrootでビルドされるツールチェイン をビルドするためのMakefileと設定
• /toolchain : ツールチェインをビルドするためのMakefileと設定
• /tools : ビルドプロセス全体で使用される様々なツール

Generating releases has already been vastly automated. The remaining parts of the process need to also be automated before the first LEDE release. We will introduce a TESTERS file that is formatted similarly to the MAINTAINERS file of the kernel. Community members can list themselves as testers for a target/profile/device. Once a release has been generated testers should receive an email informing them of the requirement for images to be tested. It needs to be decided if only tested images should be included in the binary release.

リリースは以下の条件を満たすことが求められています:

1. 最低でも年1回のリリース
2. 最低1回のメンテナンスアップデート
3. リリース後, 少なくとも1年間はCVEや重大な問題の修正を提供すること
4. メンテナンスされているターゲットのみを含むこと
5. 実際のデバイス上でテストされたことのあるターゲットのみを含むこと
6. （特定の期日にリリースするのではなく）準備が整ったタイミングでリリースすること

詳細については、TODOページをご覧ください。

git.openwrt.org で自分用のステージングツリーを作成する方法（一般ユーザーには適用されません）:

ssh git@git.openwrt.org "create openwrt/staging/yournick"
ssh git@git.openwrt.org "desc openwrt/staging/yournick Staging tree of Your Name"

https://git.openwrt.org で自分のステージングツリーを可視にするには:

ssh git@git.openwrt.org "perms openwrt/staging/yournick + READERS gitweb"

自分のステージングツリーを誰でも読み取りアクセスできるようにするには:

ssh git@git.openwrt.org "perms openwrt/staging/yournick + READERS @all"

リース後2日以内に常に最新のカーネルに移行することは、実際には非現実的で時間の無駄であることが証明されています。 これにより、以下の問題が発生しました:

1. カーネルバージョンの分散
2. メンテナが安定化よりも常にアップグレードを優先することを強いられるプレッシャー
3. リリースとリリースの間に発生する3~4回のカールアップデートに膨大な労力が投じられる
4. kmod-* パッケージの維持に対する大量の作業負担
5. 完全にテストされていない可能性のあるカーネルへのアップグレード

もちろん、古くて使われなくなったカーネルを放置する言い訳にはなりません。 コミュニティに最新のカーネルを提供しつつも、不要な作業負担や安定性の問題を引き起こさない、2つの間でバランスの取れた道を選ぶべきです。

同時に存在するカーネルバージョンは最大で3つにすべきです。 並行して存在するバージョンは2つだけにする方が3つよりも良いです。

要するに、最先端よりも安定性を重視すべきです。 最先端技術は重要ですが、安定性を犠牲にするものではありません。