Hi,

as we started to have different branches and repositories, everything became a little bit more complex to track. I will try to summarize what and where is something going on inside the batman-adv universe.

There is currently one main change happening in the branch design. The branch currently called 'maint' will be renamed to 'next'. This should reflect that we work there on the features (already part of master/trunk) which should be submitted to the kernel maintainers. This branch is stopped quite early in the development phase - even before the kernel with the corresponding features will be released.

For example the current patches for linux 2.6.36 (which will may be released in 5 weeks) will be finished with the release of v2010.1.0. The next branch will get immediately all patches which will be part of linux 2.6.37. This is needed because all patches must be tested in linux-next a long time before Linus Torvalds opens the merge window vor linux 2.6.37.

Of course, this will create a small gap for bug fixes which will enter linux 2.6.36 after the release of v2010.1.0. That's why we now use the maint branch to track those changes. Maint will always be a branch on top of the last release with all bugfixes which must be added to that release and are not features for the next branch.

That new maint branch will also help other distributors to easily find patches which should be applied on top of their shipped versions or for users which want to build their version of batman-adv manually and still get a version which fixes (hopefully) all know bugs. And maybe we will have bug fix releases in the future...

* trunk/batman-adv/ [1], master [2]

In trunk is always summer - so changes always(?) enter here and will get moved to other branches unless they need some more time to get a fine flavor - or at least more testing. Even if everything should hit trunk, it is easier to describe changes in a different places (next, master-rebase).

This branch can be used together with trunk/batctl/ [3]

* next [4]

This is were commits are gathered to be send later to the linux kernel folks. Only tested features or features which are dependencies for the in-kernel batman-adv should enter this branch.

Since the last time [5] many things happened, but not all are finished yet. So for example the release of v2010.1.0 is still pending and so no patches for linux-2.6.37 have been send to GregKH.

Meanwhile we had to deal a little bit with some regressions which were added when we changed to everything from procfs to sysfs. This is the reason why there were some patches sent to the linux stable-tree folks lately.

After that release we we will merge some patches which are mostly needed to push the merge of batman-adv into linux-net a little bit further. That includes for example the preparation of nearly all data inside of skbs instead of external buffers and the usage of optimized kernel functionality for things which we tried to implement our self. But of course there are again quite interesting features:

* batman-adv: layer2 unicast packet fragmentation * batman-adv: attach each hard-interface to a soft-interface * batman-adv: multiple mesh clouds

Also patches were added which tweaked a little bit here and there. Many of them came directly from the kernel folks and dealt with smaller coding style problems.

This branch can be used together with batctl-next [6]

* linux-2.6.36

The release of linux 2.6.36 isn't finished yet, but we have submitted all patches in next. We aren't yet in net/, but hope that this follows soon. All problems which David S. Miller [7] found were relative small and already fixed. We will wait until the first patches for the upcoming merge window were send to the staging tree, before we try to get really into net/.

You may experienced some weird regressions when using early -RCs of linux 2.6.36. Those happened due to some smaller patch war between the guys from linux-net and us. Those changes clashed when GregKH had to merge them after the release of 2.6.35. Unfortunately he resolved the merge conflicts a little bit different than I expected. But those problems should be solved with the upcoming release of linux 2.6.36-rc3.

* linux [8]

The dirty place were all the linux integration happens. It is ugly, misunderstood and uninteresting for most people.

The last synchronization point was GregKH-20100821 [9]. It is a merge of linux-2.6.36-rc1 and v2010.0.0-46-ge3a0cc9 [10] + a documentation of all files we create in sysfs. So this synchronization point (a git tag) just says that we checked at least linux-2.6.36-rc1 for new patches not yet integrated in next/trunk of batman-adv and that we send our changes until that point to GregKH [11].

* rebase [12]

My personal playground. (With a little delay) I will try to get all changes in trunk rebased on top of next. As result we get only the essence of changes in trunk which aren't already part of next. This also means for example that patches will look like they were made with sysfs in mind when they are originally created files in /proc. Even when I always ensure that the files in master and rebase are 100% equal, the original author may not be blamed when a single patch will try to eat your pet (or you could say that patches in that branch will not be checked by their original authors and I will only guarantee that when you apply all patches you will get the same files as in trunk).

Nevertheless it is a great place to get and test feature patches on top of next without using the complete set of changes in master. Or to understand what goes on in trunk compared to next.

After the release of v2010.1.0 we will only have the gateway patches again waiting to get merged into next.

* batman-adv: adapting source version to revised versioning scheme [13] * batman-adv: adding gateway functionality [14] * batman-adv: send DHCP requests directly to the chosen gw [15] * batman-adv: best gw DHCP filter 802.1Q support [16]

This branch will jump around and it is not save to track it using a local git branch.

It can be used together with trunk/batctl/ [3]

Maybe this is a good place to announce that there is something like master-rebase also to rebase current patches of batctl [17] on top of the latest release. It is unknown who will continue the work on that, but as it is not as complex at the kernel module, I doubt that it is really much work rebase and reorder those patches.

Last but not least, thanks to everyone who has done the real work

* Andreas Langer * Joe Perches * Linus Lüssing * Marek Lindner * Randy Dunlap * Simon Wunderlich

Special thanks goes to

* Kazuki Shimada * Tim Glaremin

for extensive testing and debugging help. Lets see what the next months will bring us.

Best regards, Sven

[1] http://downloads.open-mesh.org/svn/batman/trunk/batman-adv/ [2] http://git.open-mesh.net/?p=batman-adv.git;a=shortlog;h=refs/heads/master [3] http://downloads.open-mesh.net/svn/batman/trunk/batctl/ [4] http://git.open-mesh.net/?p=batman-adv.git;a=shortlog;h=refs/heads/next [5] http://git.open-mesh.net/?p=batman-adv.git;a=shortlog;h=13bc17ebf3e6062d9267... [6] http://git.open-mesh.net/?p=batctl.git;a=shortlog;h=refs/heads/next [7] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2010-July/003141.html [8] http://git.open-mesh.net/?p=ecsv/linux-merge.git;a=shortlog;h=refs/heads/lin... [9] http://git.open-mesh.net/?p=ecsv/linux-merge.git;a=commit;h=GregKH-20100821 [10] http://git.open-mesh.net/?p=batman-adv;a=commit;h=e3a0cc90940915dd14e4ca6bda... [11] http://open-mesh.net/wiki/SubmittingLinux [12] http://git.open-mesh.net/?p=ecsv/master-rebase.git;a=shortlog;h=rebase [13] http://git.open-mesh.net/?p=ecsv/master-rebase.git;a=commit;h=5900c5e655797f... [14] http://git.open-mesh.net/?p=ecsv/master-rebase.git;a=commit;h=efd570e04d1499... [15] http://git.open-mesh.net/?p=ecsv/master-rebase.git;a=commit;h=1f498c63ae1313... [16] http://git.open-mesh.net/?p=ecsv/master-rebase.git;a=commit;h=791290fc06e64b... [17] http://git.open-mesh.net/?p=ecsv/batctl-rebase.git;a=shortlog;h=rebase