On Tuesday, June 21, 2011 10:01:24 PM Andrew Lunn wrote:
Explain to David that these changes are in the pipeline. Explain what benefits they bring. And probably most importantly, try to promise they will all arrive at once. This might mean delaying some features for a while, but it will upset compatibility the least. After that, there will not be any none compatible changes for "a long time". We should discussion here what "a long time" means, eg 4 kernel cycles, 8 kernel cycles, etc.
[..]
The point of this is to put infrastructure in place to allow the protocol to be extended without breaking compatibility. It will limit what can be added as new features, cause more headaches while figuring out how to implement something using only this infrastructure, but will keep a lot of people happy they don't need a flag day when upgrading their kernel to an incompatible batman-adv version.
Merging all "big" features at once does not seem feasible. We still want to be able to deliver something that does not break each and every bit at the same time. I also doubt that David would be happy with a big blob to be merged at once. In case you refer to aggregating compatibility changes - that is what we did. This patchset not only contained the TT protocol changes but also the TTL header changes we discussed at the WBMv4.
For the upcoming routing protocol changes I propose the following: First we abstract the routing handling and adjust the current routing algo to be usable. Then we add a compile time option to choose this algo or the older one (afaik the wireless folks do the same with their rate control algorithm). The new algo can be marked as experimental and be completed step by step.
Cheers, Marek