From: Jo-Philipp Wich Date: Sun, 3 Apr 2016 23:33:13 +0000 (+0200) Subject: Rename source to development to better reflect the contents. X-Git-Url: http://git.cdn.openwrt.org/?a=commitdiff_plain;h=93b6202b06e551abcc350763e533f6fec9ffcce7;p=web.git Rename source to development to better reflect the contents. Signed-off-by: Jo-Philipp Wich --- diff --git a/pages/development.txt b/pages/development.txt new file mode 100644 index 0000000..fa72935 --- /dev/null +++ b/pages/development.txt @@ -0,0 +1,140 @@ +LEDE Development +================ + +include::menu.inc[] + +== The Source Code + +The LEDE project source code start off with OpenWrt revision r49083. 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 comitter names and mail addresses. + +All repositories can be browsed online through +http://git.lede-project.org/[Gitweb] as well. + +=== Getting The _LEDE_ Code + +Any _LEDE_ development happens in the main +source.git+ repository which is +accessible via both HTTP and HTTPS: + +---- +git clone http://git.lede-project.org/source.git +---- + +=== Getting the OpenWrt Code + +We keep the original OpenWrt source code up to r49083 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 http://git.lede-project.org/openwrt/source.git +git clone http://git.lede-project.org/openwrt/packages.git +git clone http://git.lede-project.org/openwrt/feeds.git +git clone http://git.lede-project.org/openwrt/docs.git +---- + +=== The Web Presence + +The pages you're reading are generated from text files using the +http://www.methods.co.nz/asciidoc/[AsciiDoc] suite. Any changes made to the +projects web site will be reflected in our +web.git+ repository: + +---- +git clone http://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 constitute 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 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. + +. 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 outside 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 impractical and a time killer 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 stabilise +. 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 maintenance 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/menu.inc b/pages/menu.inc index c9562a1..158630e 100644 --- a/pages/menu.inc +++ b/pages/menu.inc @@ -2,7 +2,7 @@ . pass:attributes[About] . pass:attributes[Communication] . pass:attributes[Rules] -. pass:attributes[Source] +. pass:attributes[Development] . pass:attributes[Todo] . pass:attributes[Meetings] . pass:attributes[Documentation] diff --git a/pages/source.txt b/pages/source.txt deleted file mode 100644 index b44b659..0000000 --- a/pages/source.txt +++ /dev/null @@ -1,140 +0,0 @@ -Source Code Repositories -======================== - -include::menu.inc[] - -== The Source Code - -The LEDE project source code start off with OpenWrt revision r49083. 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 comitter names and mail addresses. - -All repositories can be browsed online through -http://git.lede-project.org/[Gitweb] as well. - -=== Getting The _LEDE_ Code - -Any _LEDE_ development happens in the main +source.git+ repository which is -accessible via both HTTP and HTTPS: - ----- -git clone http://git.lede-project.org/source.git ----- - -=== Getting the OpenWrt Code - -We keep the original OpenWrt source code up to r49083 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 http://git.lede-project.org/openwrt/source.git -git clone http://git.lede-project.org/openwrt/packages.git -git clone http://git.lede-project.org/openwrt/feeds.git -git clone http://git.lede-project.org/openwrt/docs.git ----- - -=== The Web Presence - -The pages you're reading are generated from text files using the -http://www.methods.co.nz/asciidoc/[AsciiDoc] suite. Any changes made to the -projects web site will be reflected in our +web.git+ repository: - ----- -git clone http://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 constitute 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 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. - -. 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 outside 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 impractical and a time killer 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 stabilise -. 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 maintenance 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.