[B.A.T.M.A.N.] The state of batman-adv branches in august 2010

[B.A.T.M.A.N.] The state of batman-adv branches in august 2010

[Sven Eckelmann]

[-- Attachment #1: Type: Text/Plain, Size: 8631 bytes --]

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=13bc17ebf3e6062d92673a31f1b60a2e60f85813
[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/linux
[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=e3a0cc90940915dd14e4ca6bdab6d74bbc60f4a4
[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=5900c5e655797f2470532a1e1d1eb42dd55fd890
[14] http://git.open-mesh.net/?p=ecsv/master-rebase.git;a=commit;h=efd570e04d14993a837711fc150562574a53a835
[15] http://git.open-mesh.net/?p=ecsv/master-rebase.git;a=commit;h=1f498c63ae13135af1950809f4d5e41a1b509718
[16] http://git.open-mesh.net/?p=ecsv/master-rebase.git;a=commit;h=791290fc06e64b779c6b0ee776d3273484692058
[17] http://git.open-mesh.net/?p=ecsv/batctl-rebase.git;a=shortlog;h=rebase

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]