Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
| docs:guide-developer:source-code:start [2018/12/08 13:27] – update staging tree instructions jow | docs:guide-developer:source-code:start [2021/08/01 10:48] – [The OpenWrt source code] spelling vgaetera | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== The OpenWrt | + | ====== The OpenWrt |
| + | See also: [[docs: | ||
| The OpenWrt project source code is stored inside a git tree which contains all branches and releases ever made. | The OpenWrt project source code is stored inside a git tree which contains all branches and releases ever made. | ||
| All repositories can be browsed online through: | All repositories can be browsed online through: | ||
| + | - [[https:// | ||
| + | - [[https:// | ||
| - | - [[https:// | + | ===== OpenWrt |
| - | - [[https:// | + | |
| - | + | ||
| - | + | ||
| - | ===== OpenWrt | + | |
| Any //OpenWrt// development happens in the main '' | Any //OpenWrt// development happens in the main '' | ||
| - | < | + | < |
| git clone https:// | git clone https:// | ||
| </ | </ | ||
| - | You can find a mirror of the repository on Github: | + | You can find a mirror of the repository on GitHub: |
| - | < | + | < |
| git clone https:// | git clone https:// | ||
| </ | </ | ||
| ==== General source structure ==== | ==== General source structure ==== | ||
| - | |||
| These are the folders you can find in the project’s git: | These are the folders you can find in the project’s git: | ||
| - | |||
| * **/config** : configuration files for menuconfig | * **/config** : configuration files for menuconfig | ||
| * **/ | * **/ | ||
| Line 36: | Line 32: | ||
| ===== Releases ===== | ===== Releases ===== | ||
| - | + | Generating Releases has already been vastly automated. | |
| - | 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/ | + | 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/ | ||
| + | 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. | ||
| Releases should: | Releases should: | ||
| - | |||
| - Happen at least once a year | - Happen at least once a year | ||
| - Have at least one maintenance update | - Have at least one maintenance update | ||
| Line 51: | Line 50: | ||
| ===== Staging Trees ===== | ===== Staging Trees ===== | ||
| + | To create yourself a staging tree on git.openwrt.org (does not apply to regular users): | ||
| - | To create yourself a staging tree on git.openwrt.org (does not apply to regular users): | + | < |
| - | + | ssh git@git.openwrt.org " | |
| - | < | + | |
| - | ssh git@git.openwrt.org " | + | |
| ssh git@git.openwrt.org "desc openwrt/ | ssh git@git.openwrt.org "desc openwrt/ | ||
| </ | </ | ||
| Line 61: | Line 59: | ||
| To get your staging tree visible at https:// | To get your staging tree visible at https:// | ||
| - | < | + | < |
| ssh git@git.openwrt.org "perms openwrt/ | ssh git@git.openwrt.org "perms openwrt/ | ||
| </ | </ | ||
| Line 67: | Line 65: | ||
| To get your staging tree read accessible to everyone: | To get your staging tree read accessible to everyone: | ||
| - | < | + | < |
| ssh git@git.openwrt.org "perms openwrt/ | ssh git@git.openwrt.org "perms openwrt/ | ||
| </ | </ | ||
| ==== Kernel updates ==== | ==== Kernel updates ==== | ||
| - | + | It has proven impractical and a waste of time to always be on the very latest kernel within 2 days of its release. | |
| - | It has proven impractical and a waste of time to always be on the very latest kernel within 2 days of its release. It has caused the following: | + | It has caused the following: |
| - diversification of kernel versions | - diversification of kernel versions | ||
| - pressure on maintainers to constantly upgrade rather than stabilize | - pressure on maintainers to constantly upgrade rather than stabilize | ||
| Line 81: | Line 78: | ||
| - Upgrade to kernels that might not be fully tested | - Upgrade to kernels that might not be fully tested | ||
| - | Obviously, this doesn' | + | Obviously, this doesn' |
| - | + | A balanced path between the 2 should be taken that gives the community recent kernels without causing unnecessary workload and stability issues. | |
| - | There should be a max of three concurrent kernel versions. Having only two concurrent versions is better than three. | + | |
| - | + | ||
| - | In Short - stability should be valued higher than bleeding edge. Bleeding edge is important -- but not as a trade-off to stability. | + | |
| - | + | ||
| - | ===== Adding a New Device ===== | + | |
| - | **[[docs: | + | There should be a max of three concurrent kernel versions. |
| + | Having only two concurrent versions is better than three. | ||
| + | In short, stability should be valued higher than bleeding edge. | ||
| + | Bleeding edge is important, but not as a trade-off to stability. | ||