commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bridge-loop-avoidance-II (7569b1b0)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/News-archive (2f1ea62e)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 2f1ea62e32142dc21a39b315b298fdbf6b7a2939 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Sun Aug 21 16:25:43 2011 +0000 doc: open-mesh/News-archive >--------------------------------------------------------------- 2f1ea62e32142dc21a39b315b298fdbf6b7a2939 open-mesh/News-archive.textile | 1 + 1 file changed, 1 insertion(+) diff --git a/open-mesh/News-archive.textile b/open-mesh/News-archive.textile index 5f962dcf..02a57c81 100644 --- a/open-mesh/News-archive.textile +++ b/open-mesh/News-archive.textile @@ -6,6 +6,7 @@ This page contains the links to previous news posts for archiving puposes. h3. 2011 +* *30.Mar. 2011* [[2011-03-30-GSoC2011-announcement|B.A.T.M.A.N. @Google Summer of Code 2011]] * *27.Mar. 2011* [[2011-03-27-transition-to-git|Transition to git]] * *17.Mar. 2011* [[2011-03-17-batman-adv-and-the-penguin|Batman-adv and the Penguin join forces]] * *29.Jan. 2011* [[2011-01-29-batman-adv-2011-0-0-release|Batman-adv 2011.0.0 released]]

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/WikiStart (c54b946e)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit c54b946e2d1aa5b1b2085204534dd4feaf76bfb1 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Sun Aug 21 16:26:24 2011 +0000 doc: open-mesh/WikiStart >--------------------------------------------------------------- c54b946e2d1aa5b1b2085204534dd4feaf76bfb1 open-mesh/WikiStart.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/open-mesh/WikiStart.textile b/open-mesh/WikiStart.textile index c2354333..e4735b4f 100644 --- a/open-mesh/WikiStart.textile +++ b/open-mesh/WikiStart.textile @@ -10,11 +10,11 @@ B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is a routing protocol h2. News +* *21.Aug. 2011* [[2011-08-21-batman-adv-2011-3-0-release|Batman-adv 2011.3.0 released]] * *18.Aug. 2011* [[2011-08-18-network-coding-first-steps|First steps towards Network Coding]] * *01.Jul. 2011* [[2011-07-01-GSoC2011-status|GSoC 2011 status update]] * *19.Jun. 2011* [[2011-06-19-batman-adv-2011-2-0-release|Batman-adv 2011.2.0 released]] * *19.Apr. 2011* [[2011-04-18-batman-adv-2011-1-0-release|Batman-adv 2011.1.0 released]] -* *30.Mar. 2011* [[2011-03-30-GSoC2011-announcement|B.A.T.M.A.N. @Google Summer of Code 2011]] * [[news-archive|news archive]]

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Release-todo (9af8a546)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 9af8a5466b08e9f30799e956bff6aa5184b37fe8 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Sun Aug 21 16:30:29 2011 +0000 doc: batman-adv/Release-todo >--------------------------------------------------------------- 9af8a5466b08e9f30799e956bff6aa5184b37fe8 batman-adv/Release-todo.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Release-todo.textile b/batman-adv/Release-todo.textile index a078bda8..d336c21e 100644 --- a/batman-adv/Release-todo.textile +++ b/batman-adv/Release-todo.textile @@ -36,7 +36,7 @@ h2. Release * [x] build package tar.gz and generate checksums * [x] move packages/checksums to stable/sources / create symlinks from releases * [x] update download links in the redmine downloads page -* [ ] send release mail +* [x] send release mail * [x] update IRC channel topic

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/OGMv2 (ee1cda6e)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit ee1cda6ebcb58608ac41ccbb156f437eccacfba6 Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Sun Aug 21 18:44:09 2011 +0000 doc: batman-adv/OGMv2 >--------------------------------------------------------------- ee1cda6ebcb58608ac41ccbb156f437eccacfba6 batman-adv/{OGM.textile => OGMv2.textile} | 101 +++++++----------------------- 1 file changed, 24 insertions(+), 77 deletions(-) diff --git a/batman-adv/OGM.textile b/batman-adv/OGMv2.textile similarity index 69% copy from batman-adv/OGM.textile copy to batman-adv/OGMv2.textile index 074eb675..e9c9ce53 100644 --- a/batman-adv/OGM.textile +++ b/batman-adv/OGMv2.textile @@ -1,6 +1,7 @@ h1. Originator Message (OGM) ??This page is work-in-progress and will state the BATMAN V algorithm later.?? +It is a rework based on the original [[OGM]] page and will supercede it after completion. h2. 1. Introduction @@ -11,7 +12,7 @@ With the new concept of a separate [[ELP|ELP]] the tasks performed by OGMs becom This bears the following advantages from the OGM point of view: * Reduced overhead, as OGMs can then be send with a slower interval. The BATMAN routing algorithm still has a squared amount of overhead in worst case scenarios, therefore the the slower intervals are very desireable. * The BATMAN core routing protocol becomes less entangled with other mechanisms and features, making it easier understand and to perform theoretical analysis on. -* Easier to optimize the OGMs convergence speed. + h2. 2. Definitions @@ -104,54 +105,49 @@ Upon receiving an OGM a node must perform the following checks before the packet h4. 4.2.1. Preliminary Checks -* If the OGM contains a version which is different to the own internal version the message must be silently dropped (thus, it must not be further processed). -* If the sender address of the OGM is an ethernet multicast (including broadcast) address the message must be silently dropped. -* If the destination address of the OGM is a unicast address the message must be silently dropped. -* If the originator address of the OGM is our own the message must be silently dropped as this OGM originated from this node. +The following checks are simple sanity checks which don't affect the routing logic: -h4. 4.2.2. Potential Router Checks +* *Version Check:* If the OGM contains a version which is different to the own internal version the message must be silently dropped (thus, it must not be further processed). +* *Source Check:* If the sender address of the OGM is an ethernet multicast (including broadcast) address the message must be silently dropped. +* *Destination Check* If the destination address of the OGM is a unicast address the message must be silently dropped. +* *Own Message Check:* If the originator address of the OGM is our own the message must be silently dropped as this OGM originated from this node. -The following steps check whether the Neighbor we received the OGM from is a potential Router, meaning that we could switch to this Neighbor without creating a routing loop. If this is not the case we are going to drop and ignore this OGM. Otherwise we will further call this Neighbor a potential Router or just Router and will pass on to the Router Ranking. +h4. 4.2.2. Potential Router Checks -* If an originator entry matching the originator address of the OGM and a Selected Router exist: -** If the OGM's Sequence Number is smaller than the Selected Router's Sequence Number then the message must be silently dropped. This step is needed to ensure loop-freeness, we may only select newer or in certain circumstances equal sequence numbers. -** If for the according originator entry's router list a router entry matching the neighbor we received the OGM from exists and this entry has a sequence number higher than the one in the OGM then the message must be silently dropped. Due to the previous check this step is not needed to ensure loop-freeness. Instead it ensures that we are not "updating" a router entry (which might not be the Selected Router at the moment) with older information. +The following steps check whether the Neighbor we received the OGM from is a potential Router. If the OGM has not been dropped after these preliminary checks, the OGM will be modified in the following way to obtain the path TQ of the received OGM: +* *Update TQ:* The OGM's TQ field needs to be multiplied with the best link TQ towards the according neighbor. This new TQ value is further referenced as path TQ. -* The OGM's TQ field needs to be multiplied with the best link TQ towards the according neighbor. This new TQ value is further referenced as path TQ. - -A final check then needs to be applied: +After that, we check the OGM against the current data we have (currently selected router and current entry): * If an originator entry matching the originator address of the OGM and a Selected Router exist: -** If the OGM's Sequence Number is equal to the Selected Router's Sequence Number and the OGM's path TQ is lower than the Selected Router's path TQ then the message must be silently dropped. This step is needed to ensure loop-freeness, an OGM of the same sequence number and a lower path TQ might have been rebroadcasted from us before and might have made any next hop along the selected path to have chosen us a a next hop again, possibly creating a routing loop. And actually we are just interested for the best path TQ for now anyway. -** If for the according originator entry's router list a router entry matching the neighbor we received the OGM from exists and this entry has a sequence number equal to the one in the OGM and the OGM's path TQ is lower than or equal to the router entry's path TQ then the message must be silently dropped. Due to the previous check this step is not needed to ensure loop-freeness. Instead it ensures that we are only updating a router entry with the same sequence number to a better path TQ (which might have arrived over a "longer", more delayed path). This is also needed to ensure in case of very low packet loss over best paths to get the best, true path TQ values within the OGM flood of one sequence number. +** *drop if seqno smaller:* If the OGMs Sequence Number is smaller than the Selected Router's Sequence Number then the message must be silently dropped. +** *drop if not best router:* If the OGMs Sequence Number is equal or higher than the Selected Router's Sequence Number, but the the router is not our best router, the message must be silently dropped. +** *seqno same, but TQ smaller:* If the OGM's Sequence Number is equal to the Selected Router's Sequence Number and the OGM's path TQ is lower than the Selected Router's path TQ then the message must be silently dropped. + +If the OGM has not been dropped so far, we will further call this Neighbor a potential Router or just Router and will pass on to the Router Ranking. h3. 5. Router Ranking -For each OGM having passed the previous checks the according neighbor is a potential, loop-free router. The Router Ranking checks whether just an according Router or even completely new Originator entry needs to be created or an already existing Router entry matching the Router we received this OGM from just updated. Or whether also the currently Selected Router needs to be switched. Furthermore step 5.2. will force relinquishing the so far Selected Router if its information became too old because of this OGM received via a Router other than the Selected Router. +The Router Ranking checks whether just an according Router or even completely new Originator entry needs to be created or an already existing Router entry matching the Router we received this OGM from just updated. Or whether also the currently Selected Router needs to be switched. Furthermore step 5.2. will force relinquishing the so far Selected Router if its information became too old because of this OGM received via a Router other than the Selected Router. If this OGM just results in updating a Router in the Router list which is not and not going to be the currently Selected Router, then no rebroadcasting of this OGM will take place in step 5.3. for now. -Finally, any Neighbors which are not loop-safe Routers anymore after a possibly newly Selected Router will be removed from the Router list in step 5.4. - - For the Router Ranking the following actions must be performed: h4. 5.1. Creating or Updating Originator and Router Entries -In this step we are updating the according entries in the Router list. Step 4.2.2 ensured that the OGM which was not dropped yet is actually containing either newer (higher sequence number) information - which is a loop-safe, possible choice because that Router or any next hop on that path did not and will not be allowed to switch back to a lower sequence number again (like the lower sequence number we would have). Or information of the same originator's OGM flooding round, the same sequence number, as the currently Selected Router but with that OGM having travelled along a better path (better due to a higher path TQ of this OGM - and note that an OGM having travelled along such a better path can never have travelled over us before, as then the path TQ would have to be worse and not better in such a case as with each hop the path TQ gets at least 1/255 worse due to the Hop Penalty, see section 7.1). The OGM with the properties just stated might also have been received from a Neighbor which we do not have a Router entry - or even an Originator entry yet which will be created in that case first. - -More precisely, the following steps need to be undertaken in the updating and creating process: +The following steps need to be undertaken in the updating and creating process: * If no originator entry matching the originator address of the OGM exists: ** Create a new originator entry with the originator address and originator's sequence number set to ones from the OGM. * If no router entry matching the OGM's originator and the neighbor the OGM was received from exists: -** Create a new router entry with the Router Address set to the address of the Router we received the OGM from. Buffer the complete OGM in this entry. +** Create a new router entry with the Router Address set to the address of the Router we received the OGM from. Buffer the complete OGM in this entry. (TODO: really?) ** Unset this new router entry's Rebroadcasted flag. * Otherwise: -** Delete the old buffered OGM and buffer this newly received OGM instead. +** Delete the old buffered OGM and buffer this newly received OGM instead. (TODO: really?) ** Unset the Rebroadcasted flag in this matching router entry. h4. 5.2. Purging Outdated Router Entries @@ -166,9 +162,7 @@ More precisely we have to: ** The new Originator's Sequence Number must be set to the Sequence Number contained in the received OGM. ** for all Routers of the OGM's originator: if (Originator's Sequence Number - Router's Sequence Number) > OGM_SEQ_RANGE, purge the router from the OGM's originator's Router List. -Note that neither applying this outdated Router purging harms loop-freeness as we would Select a new Router with a higher sequence number in section 5.3. and again, the Router that would be selected next or any next hop behind it would not have selected us or will not select us due to them not being allowed to switch back to a lower sequence number again. Nor is this purging of outdated Routers needed to ensure loop-freeness. It is just an optimization for certain scenarios as described previously. - -Also note, that this step can result in rebroadcasting an OGM in step 5.3. which is not the one we have actually received and are currently processing - which is intended: This incoming OGM might be the cause of purging outdated entries, however there might be still other loop-free Routers in the Router list which have a higher path TQ and are therefore more desirable to chose as the new Selected Router than the Router we received this OGM from. +Note that this step can result in rebroadcasting an OGM in step 5.3. which is not the one we have actually received and are currently processing - which is intended: This incoming OGM might be the cause of purging outdated entries, however there might be still other Routers in the Router list which have a higher path TQ and are therefore more desirable to chose as the new Selected Router than the Router we received this OGM from. h4. 5.3. Switching to (or Keeping) best Router @@ -231,7 +225,6 @@ h1. Questions h1. Notes -* Section 'Receiving other nodes' OGMs' ensures the loop-freeness - any OGM having past that part and is accepted and loop-safe and can potentially be used as a (new) router * 'Router Ranking' purges routers that are outdated in terms of sequence number and selects the routers with the highest path TQ. It further updates the status of the according router the OGm was received from. * With the simple ELP link quality handling the EIGRP/BABEL feasibility is not necessary as any router we could switch to due to EIGRP feasibility but not due to DSDV feasibility is actually a _worse_ choice as that router would have a lower path TQ. * The ELP link quality information could possibly be made more use of. For now, it is always applied very early when receiving the OGM and never considered anymore. It could allow us to (a) switch to another router when the link quality of our currently selected router got worse without needing a higher sequence number of the other router (with the help of EIGRP feasibility). Or (b) allow us to avoid switching to a new, other router upon receiving an OGM from a router other than our selected router because the link quality towards our currently selected router (and therefore its path TQ) increased a lot since we last received the OGM of our currently selected router. So there is potential to optimize things within the _same_ sequence number, but that'd make things more complex and error prune of course. The way it is stated here for BATMAN V at the moment should be rather straight-forward and clear and make it rather unlikely that we'd miss a case where a routing loop could occure (both conception and implementation wise). @@ -256,11 +249,11 @@ if orig_node->last_seqno - router->last_seqno > SEQ_DIFF_MAX. h2. Removed previous sender field -h2. Bonding Mode using NDP's link qualities +h2. Bonding Mode using ELP's link qualities h2. Removal of secondary interface originators -Instead when receiving an OGM, always the best link quality measured by NDP +Instead when receiving an OGM, always the best link quality measured by ELP will be substracted from the OGM. This shall make multiple interfaces transparent from the OGM algorithm. @@ -293,25 +286,6 @@ It will switch to the router with the highest path TQ which is still in the OGM_ and rebroadcast its buffered OGM instead of the just received OGM. The just received OGM will still be buffered (router-addr + seqno + path-TQ) though. -h2. Strict hop-penalty - -In BATMAN V the hop penalty always decreases the OGM's path TQ (at least by 1/255: minimum selectable -hop penalty: 1, path TQ always rounded downwards) - -Routing loops could potentially occure if a link has 0%25 packet loss and: -* Either if the hop penalty is set to 0. -* (Or if the received OGMs path TQ is very low (and hop penalty would not change the path TQ -due to rounding issues?) - -Question: Or is the TTL check in the Router Ranking actually enough? Anyways, I guess having always -monotonically decreasing path TQ values of an OGM upon rebroadcasts is probably also easier to prove -to be loop-free. And shouldn't harm anything - therefore I'd have a better feeling with that change. - -h2. Increase NDP window size to 128 packets - -With removing the Path TQ averaging, things will get too unstable otherwise. Should be -later substituted with an EWMA [1]. - ---- h1. Further Ideas for Optimizations @@ -322,7 +296,7 @@ An accepted router with the highest sequence number has the most up-to-date info h2. Also aggregate different packet types -For instance NDP + OGMs to reduce number of packets sent. +For instance ELP + OGMs to reduce number of packets sent. h2. Positive Feedback OGM rebroadcasting @@ -331,30 +305,3 @@ When for any originator thes compared to the link quality used for the last rebr h2. No OGMs if no hosts To be able to reduce the overhead by just putting some intelligent "repeater" nodes somewhere without them sending their own OGMs - -h2. OGM forwarding optimizations in asymmetric neighborhoods - -An asymmetric link can either mean that (a) TQ >> RQ or (b) TQ << RQ. -For OGMs only (b) causes trouble and reduces the propagation time of an OGM -and would therefore be the case to optimize. - -A node with a neighborhood with asymmetric links as in case (b) can be further -devided in the following three cases: -* Church-Tower-Scenario: A node in the valley has symmetric links to most of its close neighbors. -However there might be a few or a single, distant neighbor with an asymmetric link TQ << RQ -where the same node is receiving fine from but cannot forward packets that well to. -* "Valley"-Scenario: A node is surrounded by nodes with a higher transmit power, therefore -for most of its neighbors the link is asymmetric with TQ << RQ. -* Or mixtures - -The scenarios could be detected via NDP. - -h3. Extra OGM Unicasting - -In the Church-Tower-Scenario extra OGMs could be forwarded via unicast to the few nodes. -(Extra OGM broadcasts would be unfair for the other neighbors) - -h3. Extra OGM Broadcasting - -For the "Valley"-Scenario an OGM could be broadcasted more than once. -(Extra OGM Unicasting might result in too many packets) \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Packet-types (0ec9a617)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/OGMv2 (68f1dc57)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Quick-start-guide (6cc0bacd)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 6cc0bacdda7f3b4450b0d9928695e07b92068b41 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Mon Aug 22 01:03:12 2011 +0000 doc: batman-adv/Quick-start-guide >--------------------------------------------------------------- 6cc0bacdda7f3b4450b0d9928695e07b92068b41 batman-adv/Quick-start-guide.textile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/batman-adv/Quick-start-guide.textile b/batman-adv/Quick-start-guide.textile index b86ea72a..09f374ec 100644 --- a/batman-adv/Quick-start-guide.textile +++ b/batman-adv/Quick-start-guide.textile @@ -33,7 +33,7 @@ h3. simple mesh network On all nodes, install batman-adv, load the module and enter the following commands: <pre> -ifconfig wlan0 mtu 1527 +ifconfig wlan0 mtu 1528 iwconfig wlan0 mode ad-hoc essid my-mesh-network ap 02:12:34:56:78:9A channel 1 </code></pre> @@ -45,7 +45,7 @@ ifconfig bat0 up You can now use the automatically assigned IPv6 link-local adresses on bat0 (usually starting with fe80::...), modern operating systems should support this. Or you can assign IPv4 addresses manually on all those nodes (i.e. 'ifconfig bat0 192.168.123.x/24') or one of the laptops in range has to have a DHCP server running on the bat0 interface. As batman-adv is operating on layer 2, even dhcp-messages can be send over the mesh network. -+Note:+ batman-adv inserts an additional header of 27 bytes into each data packet being send over the mesh. Therefore we are increasing the maximum size of a packet over the plain interfaces to 1527, so that packets with the standard MTU of 1500 can pass normaly through bat0. You might also decrease the MTU to 1473 on all hosts but is usually just do-able in more or less static- and small-scaled mesh-networks. ++Note:+ batman-adv inserts an additional header of 28 bytes into each data packet being send over the mesh. Therefore we are increasing the maximum size of a packet over the plain interfaces to 1528, so that packets with the standard MTU of 1500 can pass normaly through bat0. You might also decrease the MTU to 1472 on all hosts but is usually just do-able in more or less static- and small-scaled mesh-networks. h3. mixing non-B.A.T.M.A.N. systems with batman-adv @@ -55,7 +55,7 @@ If you have a couple of computers that you don't want to run batman-adv on but y On each mesh access point, install batman-adv first, load the module and enter the following commands: <pre> -ifconfig wlan0 mtu 1527 +ifconfig wlan0 mtu 1528 iwconfig wlan0 mode ad-hoc essid my-mesh-network ap 02:12:34:56:78:9A channel 1 </pre>

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Release-todo (22b85aef)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 22b85aef28cec36d01b5d9647e3ad01ed17d27c9 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sun Aug 21 15:01:13 2011 +0000 doc: batman-adv/Release-todo >--------------------------------------------------------------- 22b85aef28cec36d01b5d9647e3ad01ed17d27c9 batman-adv/Release-todo.textile | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/batman-adv/Release-todo.textile b/batman-adv/Release-todo.textile index a2da2d55..5de01aaf 100644 --- a/batman-adv/Release-todo.textile +++ b/batman-adv/Release-todo.textile @@ -14,11 +14,11 @@ h2. Release Scheduling h2. Code -* [ ] make sure all code contains the release version strings -* [ ] update copyright years (if needed) -* [ ] remove dead code (if any) -* [ ] check against kernel versions -* [ ] check that maint branch is merged in next +* [x] make sure all code contains the release version strings +* [x] update copyright years (if needed) +* [x] remove dead code (if any) +* [x] check against kernel versions +* [x] check that maint branch is merged in next * [x] check for open patches on the ml * [ ] git tag release

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Release-todo (1d72e6ef)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 1d72e6ef3c3b863a25a1cf00be1673c0d6c0fb60 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sun Aug 21 15:49:55 2011 +0000 doc: batman-adv/Release-todo >--------------------------------------------------------------- 1d72e6ef3c3b863a25a1cf00be1673c0d6c0fb60 batman-adv/Release-todo.textile | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/batman-adv/Release-todo.textile b/batman-adv/Release-todo.textile index 5de01aaf..d7094b8e 100644 --- a/batman-adv/Release-todo.textile +++ b/batman-adv/Release-todo.textile @@ -20,13 +20,13 @@ h2. Code * [x] check against kernel versions * [x] check that maint branch is merged in next * [x] check for open patches on the ml -* [ ] git tag release +* [x] git tag release h2. Documentation -* [ ] build changelog -* [ ] update README +* [x] build changelog +* [x] update README * [x] write release announcement * [ ] update wiki documentation @@ -37,7 +37,7 @@ h2. Release * [ ] move packages/checksums to stable/sources / create symlinks from releases * [ ] update download links in the redmine downloads page * [ ] send release mail -* [ ] update IRC channel topic +* [x] update IRC channel topic h2. Distributions @@ -48,7 +48,7 @@ h2. Distributions h2. Aftershow -* [ ] Merge next into master branch (to get changes on README, CHANGELOG, ...) -* [ ] Merge current git tag into maint (must be fast-forward or pre-tagging steps were done wrong) -* [ ] Merge patches from master into next (to get all the fancy new features) +* [x] Merge next into master branch (to get changes on README, CHANGELOG, ...) +* [x] Merge current git tag into maint (must be fast-forward or pre-tagging steps were done wrong) +* [x] Merge patches from master into next (to get all the fancy new features) * [ ] Rebase patches in next on top of linux-next and send it to kernel maintainers for future kernels ([[SubmittingLinux]])

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017