Re: [B.A.T.M.A.N.] RFC: Removing one indirection layer for patches

[Andrew Lunn <andrew@lunn.ch>]

Hi Sven

I've been working on Marvell SoC chips for the last few months, mostly
those used in NAS devices. Maybe a few comments from a different
corner of the kernel may be useful. But this corner is also quite
different, so not everything i say bellow may be relevant for BATMAN.
We are about the same size in terms of number of active developers,
but our methodology is quite different.

It seems like the biggest problem is the late feedback from David
S. Miller, et al, about patches. Getting this feedback earlier in the
life of a patchset would easy people lives.

For Marvell work, we post all our patches to the linux arm kernel
list, where the ARM maintainers will see the patches. All patches go
there, in all stages of their life, from early RFCs, to patches we
want the upstream maintainers to take in a following pull request.
Thus there is the possibility to get early feedback from the upstream
maintainers and avoid most last minutes surprises.

So maybe it would be good to stop using BATMAN mailing list for
patches and instead use netdev. Or at least CC: netdev.

We try, but often fail, to send pull requests early. The arm-soc
maintainers will accept pull requests at any time and queue them up in
there for-next tree. Sending pull request during -rc2 or -rc3 is not a
problem and if the maintainer decides to reject it, you have a few
weeks before -rc6/-rc7 and impending opening of the merge window.

We don't have anything like a master tree. Each developers work on his
own clone of linus's tree, generally on the last -rc tag. We have a
nominal lead maintainer, who builds trees for pull requests direction
arm-soc maintainers. This maintainer takes either patches from the
linux-arm-kernel mailing list, or pull request from other Marvell
developers, shapes up the tree in the form the arm-soc maintainer
likes, and sends pull-requests when ready. The tree is then throw
away.

The BATMAN master tree, if i understand correctly, is to allow
releases for older kernels? Maybe turn the process around? When Linus
makes a release, pull the mainline code into a branch, add in the
compat stuff and release a tarball from that? If any stable patch
touches the batman code, again, import it and make a new tarball.

We also make use of the -rc tags and the around 7 weeks before final
release for testing. Testing of these releases probably has more value
than testing of BATMAN master, or for-next, since any other changes in
the stack are included and issues because of changes outside of BATMAN
will be found. I've never had problems getting fixes into -rc
releases.

Just some ideas....

     Andrew