The Source Code

The LEDE project source code starts off with OpenWrt revision r49258. The code is stored inside a git tree which contains all branches and releases ever made by OpenWrt. While importing the sources the tree was normalised and some minor tweaks were made to committer names and mail addresses.

All repositories can be browsed online through:

  1. Gitweb - the master Git repository for LEDE
  2. Github - a continually-updated mirror of Gitweb

Any LEDE development happens in the main source.git repository which is accessible via both HTTP and HTTPS:

git clone

You can find a mirror of the repository on Github:

git clone

General source structure

These are the folders you can find in the project’s git:

  • /config : configuration files for menuconfig
  • /include : makefile configuration files
  • /package : packages makefile and configuration
  • /scripts : miscellaneous scripts used throughout the build process
  • /target : makefile and configuration for building imagebuilder, kernel, sdk and the toolchain built by buildroot.
  • /toolchain : makefile and configuration for building the toolchain
  • /tools : miscellaneous tools used throughout the build process

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.

Releases should:

  1. Happen at least once a year
  2. Have at least one maintenance update
  3. Provide CVE/critical/… fixes for at least one year after the release
  4. Only include maintained targets
  5. Only include targets that have seen on device testing
  6. Be ready when they are ready

See the TODO page for more info.

To create yourself a staging tree on

ssh <> "create lede/yournick/staging" 
ssh <> "desc lede/yournick/staging Staging tree of Your Name"

To get your staging tree visible at

ssh <> "perms lede/yournick/staging + READERS gitweb"

To get your staging tree read accessible to everyone:

ssh <> "perms lede/yournick/staging + READERS @all "

Submitting Patches

Patches can be submitted as either a pull request on Github or small fixes and minor patches can also be submitted via the mailing list. Submissions should follow the following rules:


There are Github mirrors of the source and web repos. Simply fork the project to a public repo using Github web interface, clone the repo to your computer, create a branch for your changes, push these back to Github and submit a pull request.

For example, to submit a pull request for the LEDE source, follow these instructions and then submit PR using Github web interface:

git clone
git checkout -b <branch-name>
  <make changes to files>
git commit --signoff
git push --all


Send an email to the development mailing list. All patches need to be sent in the same format as those that are listed on patchwork. If the patch does not get listed in patchwork then it won't get processed. For example, to print a patch for the most recent commit, git format-patch -1 –stdout. Double check that your output conforms before sending.

Patch Merging And Tree Life Cycle

We encourage committers to host their own staging trees where they aggregate patches that they feel responsible for and/or ones that they created themselves. Once the tree has been reviewed and tested it can be proposed for inclusion in the master branch.

  1. Trees will be merged into master at any time
  2. Bug fixes can be merged into master directly
  3. PRs can be sent to the patches mailing list from any source and will always be considered for inclusion if the quality of the tree is good and format of submission is correct
  4. Staging trees can be hosted as part of the projects git infrastructure, private servers, …

Kernel updates

It has proven impractical and a time killer to always be on the very latest kernel within 2 days of its release. It has caused these issues.

  1. diversification of kernel versions
  2. pressure on maintainers to constantly upgrade rather than stabilize
  3. huge effort invested to upgrade 3-4 times between releases
  4. huge workload to maintain kmod-* packaging
  5. Upgrade to kernels that might not be fully tested

This is obviously not an invite to sit on ancient and dusty kernels. A sane path in between should be taken that give the community recent kernels without causing unnecessary workload and stability issues.

There should be a max of three concurrent kernel version. Having only two concurrent versions is better than three.

In Short - stability should be valued higher than bleeding edge, although bleeding edge is also important, but not as a trade-off to stability.

Please note: reporting a bug is important as it raises awareness of an issue, but it does not constitute a claim that anyone has to work on fixing it.

Please report your bugs using our issue tracker
When reporting bugs please make sure to:

  • Name the tree/revision
  • Name the affected device
  • What does it do that it should not do / what does it not do that it should do
  • Steps to reproduce
  • What you have already done to fix the problem
  • Any additional info you thinks is important

Remember, the better is your bug report, the more likely it is that it will be worked on.

Adding a new device General information about adding a new device

We keep the original OpenWrt source code up to r49258 available, mostly as reference and for historic interest.

The original OpenWrt Subversion repository has been split up into several Git repositories mapping the various SVN directories and tags to proper Git branches.

git clone 
git clone 
git clone 
git clone