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