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

[Antonio Quartulli <ordex@autistici.org>]

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

Hi Andrew,

I have a few comments on what you wrote:

On Wed, Dec 05, 2012 at 11:35:27AM +0100, Andrew Lunn wrote:
> Hi Sven

[...]

> We don't have anything like a master tree. 

Yeah, I think this is exactly Sven's point. In the end, the whole email from
Sven can be concentrated in the suggestion to think about this direction, imho.

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

The master branch is used to create the out-of-the-kernel-tree package that we
release every now and then (Actually together with each kernel release).

I think the major advantage here is that, whenever a person sends a patch which
is not going to work on older kernels, he must also send a patch for compat.h/c.
This would be impossible if the patch was directly aimed to the kernel tree, or,
to say it in other words, we should each and every time run behind the committer
to ask him to send another patch for compat.

This is my feeling about the master branch/repository. I also asked to do it the
other way around, as you are suggesting, in order to also simplify (and reduce
probability of making mistakes) the process of creating pull requests. But, in
the end, we are simply moving complexity from one corner to the other.

However, I think this particular topic (patch against package vs kernel tree) is
orthogonal to what Sven is proposing.


Thank you for throwing more ideas on the plate :-)

Cheers,

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]