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

[Sven Eckelmann <sven@narfation.org>]

[-- Attachment #1: Type: text/plain, Size: 2924 bytes --]

Hi,

thanks a lot about this mail. I'll add some extra comments without any 
judgements. Your mail mostly talks about other things which are orthogonal to 
the "anti-thesis"

On Wednesday 05 December 2012 11:35:27 Andrew Lunn wrote:
> 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.

The biggest different is the "lets install a whole kernel to test this change" 
methodology ;)

Usually (please correct me) batman-adv is developed outside the kernel because 
it is easier to test stuff and it worked till now. No one of us wants to port 
the latest OpenWrt to the -rc kernel to test stuff ;)

> 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.

Partly, David switches horses relative often. So an early feedback is not as 
valuable as it sounds.

> 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.

I'll tried it in the netdev_alloc/standard interface patchset but I got only a 
surprised "where is the pull request?" reply.

> 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 also don't have this problem of getting patches accepted in -rc2 and -rc3. 
But it is funny that David's net-next/net tree hasn't catched the fresh air of 
the last -rc1.

[...]

> 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.

So the compat-driver style. I'll played around with the idea for a while but 
never came up with a working solution without a lot of extra hassle.

Kind regards,
	Sven

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