Re: [B.A.T.M.A.N.] development flow

[Andrew Lunn <andrew@lunn.ch>]

On Mon, Aug 31, 2009 at 01:26:29PM +0800, Marek Lindner wrote:
> On Monday 31 August 2009 04:23:06 Simon Wunderlich wrote:
> > Usually we have stable versions (e.g. batman-adv 0.1) with a specific
> > format, and an ongoing development in the svn trunk. Maybe we should do the
> > same for future kernel development - maintaining one packet and algorithm
> > version in the kernel, and further develop the algorithm on our own (e.g.
> > in a git tree or with sets of patches)?
> > In this case, we should post the current batman-adv to the list when
> > 0.2 is stabilized and finished. Mainline algorithm should only be changed
> > when we reach a new stable version.
> 
> Actually, I came to a similar conclusion:
> We "only" submit stable versions to mainline (including stability fixes) 
> whereas the development stays outside of the official linux tree. That way we 
> can keep our development speed without worrying too much about compatibility. 
> When we are getting to the next stable release we can think about how to 
> soften the transition. 

The rules when in staging some somewhat different when in the main
part of the tree.

The point of staging is that it allows cleanup work to be done, fixing
bad practices etc. User space APIs are not baked in stone, since bad
practices in these APIs needs cleaning up etc. So we have some
flexibility here.

Gazing into my crystal ball:

2.6.31 is out 7th September.
2.6.32 merge window ends 21st September.

Maybe GregKH prioritizes main tree patches during the window. staging
is low priority. So batman is not in 2.6.32-rc1.

Batman appears in rc2.

We have around 2 1/2 months time for cleanup work.

Sometime in December 2.6.32 is released with batman in staging.

By the time 2.6.33 is released, March 2010, we are in the main tree.


I would say we have around three months to get 0.2 finished and into
2.6.32 staging. For 2.6.33 we don't break compatibility any more and
aim to finish the cleanup and get into the main tree.

I would also suggest we post our patches as soon as possible, so we
start getting feedback from the kernel community about what else needs
adding to the TODO list etc.

       Andrew