From 126247ddfb586dd82d8b7136a6d4d6d931662bf3 Mon Sep 17 00:00:00 2001 From: John Crispin Date: Thu, 24 Mar 2016 21:02:41 +0100 Subject: [PATCH] add more content Signed-off-by: John Crispin --- pages/communication.txt | 47 +++++++++++++ pages/header.txt | 5 ++ pages/{about.txt => index.txt} | 34 ++++++---- pages/rules.txt | 19 ++++++ pages/source.txt | 117 +++++++++++++++++++++++++++++++++ pages/todo.txt | 22 +++++++ 6 files changed, 232 insertions(+), 12 deletions(-) create mode 100644 pages/communication.txt create mode 100644 pages/header.txt rename pages/{about.txt => index.txt} (85%) create mode 100644 pages/source.txt create mode 100644 pages/todo.txt diff --git a/pages/communication.txt b/pages/communication.txt new file mode 100644 index 0000000..01f30fc --- /dev/null +++ b/pages/communication.txt @@ -0,0 +1,47 @@ +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. diff --git a/pages/header.txt b/pages/header.txt new file mode 100644 index 0000000..6368387 --- /dev/null +++ b/pages/header.txt @@ -0,0 +1,5 @@ +== 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] +|==== diff --git a/pages/about.txt b/pages/index.txt similarity index 85% rename from pages/about.txt rename to pages/index.txt index e2a4953..a769862 100644 --- a/pages/about.txt +++ b/pages/index.txt @@ -1,20 +1,10 @@ +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. -=== 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: @@ -36,3 +26,23 @@ 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 :-) diff --git a/pages/rules.txt b/pages/rules.txt index 8b13789..13ad627 100644 --- a/pages/rules.txt +++ b/pages/rules.txt @@ -1 +1,20 @@ +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 diff --git a/pages/source.txt b/pages/source.txt new file mode 100644 index 0000000..ba8d452 --- /dev/null +++ b/pages/source.txt @@ -0,0 +1,117 @@ +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. diff --git a/pages/todo.txt b/pages/todo.txt new file mode 100644 index 0000000..32fc80d --- /dev/null +++ b/pages/todo.txt @@ -0,0 +1,22 @@ +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 + -- 2.30.2