pages/source.txt

   1 include::header.txt[]
   2
   3 == The Source Code
   4
   5 The LEDE project source code start off with OpenWrt revision r49083. The code
   6 is stored inside a git tree which contains all branches and releases ever made
   7 by OpenWrt. While importing the sources the tree was normalised and some
   8 minor tweaks were made to comitter names and mail addresses.
   9
  10 All repositories can be browsed online through
  11 http://git.lede-project.org/[Gitweb] as well.
  12
  13 === Getting The _LEDE_ Code
  14
  15 Any _LEDE_ development happens in the main +source.git+ repository which is
  16 accessible via both HTTP and HTTPS:
  17
  18 ----
  19 git clone http://git.lede-project.org/source.git
  20 ----
  21
  22 === Getting the OpenWrt Code
  23
  24 We keep the original OpenWrt source code up to r49083 available, mostly as
  25 reference and for historic interest.
  26
  27 The original OpenWrt Subversion repository has been split up into several Git
  28 repositories mapping the various SVN directories and tags to proper Git
  29 branches.
  30
  31 ----
  32 git clone http://git.lede-project.org/openwrt/source.git
  33 git clone http://git.lede-project.org/openwrt/packages.git
  34 git clone http://git.lede-project.org/openwrt/feeds.git
  35 git clone http://git.lede-project.org/openwrt/docs.git
  36 ----
  37
  38 === The Web Presence
  39
  40 The pages you're reading are generated from text files using the
  41 http://www.methods.co.nz/asciidoc/[AsciiDoc] suite. Any changes made to the
  42 projects web site will be reflected in our +web.git+ repository:
  43
  44 ----
  45 git clone http://git.lede-project.org/web.git
  46 ----
  47
  48 === Submitting Patches
  49
  50 The biggest difference is that we now accept pull requests. The tree that shall
  51 be pulled from needs to be hosted publicly. Small fixes and minor patches can
  52 also be submitted via the mailing list (__LINK__). Submissions should follow
  53 these rules
  54
  55 . rule N+1
  56
  57 All patches need to be sent in a format that they are listed in patchwork (__LINK__).
  58 If the patch does not get listed in patchwork then it wont get processed.
  59
  60
  61 === Reporting Bugs
  62
  63 . *All* bug reports need to be submitted via the mailing list (__LINK__)
  64 . When reporting bugs please make sure to
  65   .. Name the tree/revision
  66   .. Name the effected device
  67   .. What does it do that it should not do / what does it not do that it should do
  68   .. Steps to reproduce
  69   .. What you have already done to fix the problem
  70   .. Any additional info you thinks is important
  71 . Reporting a bug means that you reported a bug. It does not constitute a claim that
  72   anyone has to work on fixing it.
  73 . Pointless/vague/silly/... bugs reports will be ignored
  74 . Feature requests are not Bugs. They will also be ignored.
  75 . The better your bug report, the more likely it is that it will be worked on.
  76
  77 All bug reports need to be sent in a format so that they are listed in the issue
  78 tracker (__LINK__). If the bug report does not get listed in the issue tracker then
  79 it wont get processed.
  80
  81
  82 === Patch Merging And Tree Life Cycle
  83
  84 We encourage committers to host their own staging trees where they aggregate patches
  85 that they feel responsible for and/or ones that they created themselves. Once the tree
  86 has been reviewed and tested it can be proposed for inclusion in the master branch.
  87
  88 . Trees will be merged into master during a merge window
  89 . The date when the next merge window opens will be announced in advance
  90 . The window should be less than a week
  91 . Only bug fixes can be merged outside the merge window via the fixes branch (__LINK__)
  92 . No new features/update/... may be merged outside the window
  93 . PRs can be sent to the patches mailing list from any source and will always be considered
  94   for inclusion if the quality of the tree is good and format of submission is correct
  95
  96
  97 === Kernel updates
  98
  99 It has proven impractical and a time killer to always be on the very latest kernel within
 100 2 days of its release. It has caused these issues.
 101
 102 . diversification of kernel versions
 103 . pressure on maintainers to constantly upgrade rather than stabilise
 104 . huge effort invested to upgrade 3-4 times between releases
 105 . huge workload to maintain kmod-* packaging
 106 . Upgrade to kernels that might not be fully tested
 107
 108 This is obviously not an invite to sit on ancient and dusty kernels. A sane path in between
 109 should be taken that give the community recent kernels without causing unnecessary workload
 110 and stability issues.
 111
 112 There should be a max of three concurrent kernel version. Having only two concurrent versions
 113 is better than three.
 114
 115 In Short - stability should be valued higher than bleeding edge, although bleeding edge is
 116 also important, but not as a trade-off to stability.
 117
 118
 119 === Releases
 120
 121 Generating Releases has already been vastly automated. The remaining parts of the process need
 122 to also be automated before the first _LEDE_ release. We will introduce a TESTERS file that is
 123 formatted similarly to the MAINTAINERS file of the kernel. Community members can list themselves
 124 as testers for a target/profile/device. Once a release has been generated testers should receive
 125 an email informing them of the requirement for images to be tested. It needs to be decided if only
 126 tested images should be included in the binary release.
 127
 128 Releases should
 129
 130 . Happen at least once a year
 131 . Have at least one maintenance update
 132 . Provide CVE/critical/... fixes for at least one year after the release
 133 . Only include maintained targets
 134 . Only include targets that have seen on device testing
 135 . Be ready when they are ready
 136
 137 See the TODO page for more info.