+++ /dev/null
-== About LEDE
-
-The LEDE project was founded in April 2016 as an OpenWrt based spinoff with a
-strong focus on transparency, user collaboration and decentralized structures.
-
-=== Origin
-
-For a long time the OpenWrt parent project experienced infrastructure issues
-and declining developer participation on the base system while the community
-driven package ecosystem around it continued to thrive.
-
-When the number of frequently active committers reached a new low in the
-beginning of 2016, the three OpenWrt developers John Crispin, Felix Fietkau
-and Jo-Philipp Wich decided to start a new spin-off project in an attempt to
-radically change the development processes and reboot the project in better,
-community-driven manner.
-
-=== Goals
-
-LEDE's stated goals are:
-
-. Transparent decision processes with broad community participation and public
- meetings
-. Only rely on decentralized infrastructure provided by free services and
- volunteers while avoiding single points of failure to ensure maximum
- avilability of the software
-. Avoidance of developer hierarchies, "core members" and the like
-
-=== Name
-
-The name _LEDE_ is an abbreviation for Linux Embedded Development Environment,
-a reference to its flexibility and embedded buildroot origins, making it a
-solid choice for embedded Linux applications far beyound the wireless router
-and network appliance realm.
-
-The word _LEDE_ is also an alternation of the phrase _to lead_, describing
-an introductory section of a news story that is intended to entice the reader
-to read the full story.
--- /dev/null
+include::header.txt[]
+
+== Communication
+
+It is possible to communicate with other community members using mail and IRC.
+All project related communication should be done on public channels that are
+archived and easily browsable. Specific problems and tasks may be resolved
+using direct means of communication.
+
+
+=== Twitter
+
+In case of services going down, being moved or being unreachable for any other
+reason, please go to twitter and see what the status is. The project will do
+its best to post updates link:https://twitter.com/lede_project[here]
+
+
+=== Mailing Lists
+
+The project offers the following mailing lists
+
+. lede-dev - this list is used for submitting patches and general developement
+ related work
+. lede-adm - this list is used for project organisational purposes. anyone can
+ subscribe and read this list. Only committers may write to this list.
+. lede-bugs - this list is used for reporting bugs
+
+
+=== IRC Channels
+
+The project provides 2 IRC channels on freenode
+
+. #lede-dev - a public channel for everyone to join and participate
+. #lede-adm - a moderated channel that anyone can join but only people with +v flag can write on
+
+
+=== Corporate Contact
+
+There is a special email address that companies wanting to colaborate with the
+project can contact commiters confidentially. These type of "first contact" only
+have the purpose of helping companies understand the mode of operations. Once the
+intent is communicated, companies are invited to participate in the project just
+like any other community member. This means that engagement should be done in
+public. Ideally companies simply allow part of their R&D team to participate
+in the normal developement process as normal community members. There will be
+no special treatment beyond the "first contact". Please see the project
+link:rules.html[rules] for further information.
--- /dev/null
+== image:images/mock.png[width="128"] Linux Embedded Developement Environment
+
+|====
+^| link:index.html[About] ^| link:communication.html[Communication] ^| link:rules.html[Rules] ^| link:source.html[Source] ^| link:todo.html[Todo]
+|====
--- /dev/null
+include::header.txt[]
+
+== About LEDE
+
+The LEDE project was founded in April 2016 as an OpenWrt based spinoff with a
+strong focus on transparency, user collaboration and decentralized structures.
+
+=== Goals
+
+LEDE's stated goals are:
+
+. Transparent decision processes with broad community participation and public
+ meetings
+. Only rely on decentralized infrastructure provided by free services and
+ volunteers while avoiding single points of failure to ensure maximum
+ avilability of the software
+. Avoidance of developer hierarchies, "core members" and the like
+
+=== Name
+
+The name _LEDE_ is an abbreviation for Linux Embedded Development Environment,
+a reference to its flexibility and embedded buildroot origins, making it a
+solid choice for embedded Linux applications far beyound the wireless router
+and network appliance realm.
+
+The word _LEDE_ is also an alternation of the phrase _to lead_, describing
+an introductory section of a news story that is intended to entice the reader
+to read the full story.
+
+=== Origin
+
+For a long time the OpenWrt parent project experienced infrastructure issues
+and declining developer participation on the base system while the community
+driven package ecosystem around it continued to thrive.
+
+When the number of frequently active committers reached a new low in the
+beginning of 2016, the three OpenWrt developers John Crispin, Felix Fietkau
+and Jo-Philipp Wich decided to start a new spin-off project in an attempt to
+radically change the development processes and reboot the project in better,
+community-driven manner.
+
+=== Endorsement
+
+The *Wrt community is made up of many great communities all tinkering on their
+own mission in improving something on this planet. the Following communities have
+kindly decided to endorse our project. Thanks !
+
+. none so far :-)
+include::header.txt[]
+== LEDE Project Rules
+
+. There is two roles in the project: committer and non-committer
+. Committers have the right to vote on general project decisions
+. General project questions are decided with a simple majority vote
+. Committers being unreachable for three months in a row loose their commit
+ and voting rights
+. Commit means full commit. there is no partial or restricted commit.
+. Frequent contributors may become committers when a simple majority among
+ existing committers agrees
+. Votes and decisions will be made public
+. Infrastructure should be outsourced where possible
+. Any Infrastructure that cannot be outsourced needs to be accessible
+ by at elast 3 people.
+. the project does not offer email accounts under the project domain
+ (apart from abuse, admin, ...)
+. Changes to these rules require a two third majority among the committers
+ holding voting rights and shall be documented
--- /dev/null
+include::header.txt[]
+
+== The Source Code
+
+The LEDE project source code start off with OpenWrt revision r44444. The code
+stored inside a git tree. This tree contains all branches and releases ever
+mad by OpenWrt. While importing the SOurces the tree was normalized and some
+minor tweaks were made to commiter names and mail addresses.
+
+=== Getting The _LEDE_ Code
+
+----
+git clone git@git.lede-project.org:openwrt/source.git
+----
+
+=== Getting the OpenWrt Code
+
+----
+git clone git@git.lede-project.org:source.git
+----
+
+=== The Web Presence
+
+----
+git clone git@git.lede-project.org:web.git
+----
+
+=== Submitting Patches
+
+The biggest difference is that we now accept pull requests. The tree that shall
+be pulled from needs to be hosted publicly. Small fixes and minor patches can
+also be submitted via the mailing list (__LINK__). Submissions should follow
+these rules
+
+. rule N+1
+
+All patches need to be sent in a format that they are listed in patchwork (__LINK__).
+If the patch does not get listed in patchwork then it wont get processed.
+
+
+=== Reporting Bugs
+
+. *All* bug reports need to be submitted via the mailing list (__LINK__)
+. When reporting bugs please make sure to
+ .. Name the tree/revision
+ .. Name the effected 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
+. Reporting a bug means that you reported a bug. It does not constitue a claim that
+ anyone has to work on fixing it.
+. Pointless/vague/silly/... bugs reports will be ignored
+. Feature requests are not Bugs. They will also be ignored.
+. The better your bug report, the more likely it is that it will be worked on.
+
+All bug reports need to be sent in a format so that they are listed in the issue
+tracker (__LINK__). If the bug report does not get listed in the issue tracker then
+it wont get processed.
+
+
+=== Patch Merging And Tree Life Cycle
+
+We encourage commiters 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.
+
+. Trees will be merged into master during a merge window
+. The date when the next merge window opens will be announced in advance
+. The window should be less than a week
+. Only bug fixes can be merged outside the merge window via the fixes branch (__LINK__)
+. No new features/update/... may be merged ourside the window
+. 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
+
+
+=== Kernel updates
+
+It has proven impratical and a timekiller to always be on the very latest kernel within
+2 days of its release. It has caused these issues.
+
+. diversification of kernel versions
+. pressure on maintainers to constantly upgrade rather than stabilize
+. huge effort invested to upgrade 3-4 times between releases
+. huge workload to maintain kmod-* packaging
+. 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.
+
+
+=== Releases
+
+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
+
+. Happen at least once a year
+. Have at least one maintainance update
+. Provide CVE/critical/... fixes for at least one year after the release
+. Only include maintained targets
+. Only include targets that have seen on device testing
+. Be ready when they are ready
+
+See the TODO page for more info.
--- /dev/null
+include::header.txt[]
+
+== TODO List
+
+This page lists the current project wide todos
+
+=== Infrastructure
+
+. Find mirroring capacity - we liberally distribute rsync keys if you have bandwidth and storage available on trusted infrastructure contact us
+. Setup an issue tracker
+. what shall we do about wiki and forum ?
+
+=== Releases
+
+. Define pre release testing rules/guidelines
+. Decide on new naming scheme - YY.MM + animal names have been proposed as an naming option
+
+=== Buildbot Setup
+
+. Rework buildbot setup to allow running more than one build int he same tree
+. Rework buildbot setup to allow building release on the same setup
+
projects / web.git / commitdiff