Re: [B.A.T.M.A.N.] [resend][PATCHv2] staging: batman-adv: remove useless addr_to_string()

[Sven Eckelmann]

Greg KH wrote:
> On Thu, Oct 21, 2010 at 12:16:37AM +0200, Sven Eckelmann wrote:
> > On Wed, Oct 20, 2010 at 01:57:49PM -0700, Greg KH wrote:
> > > On Wed, Oct 20, 2010 at 10:51:15PM +0200, Sven Eckelmann wrote:
> > > > On Wed, Oct 20, 2010 at 06:47:44PM +0300, Andy Shevchenko wrote:
> > > > > Since all *printf() methods in the kernel understand '%pM' modifier
> > > > > the conversion to the string is useless beforehand.
> > > > > 
> > > > > Additionally this patch decreases batman_if structure by 20 bytes.
> > > > 
> > > > Thanks for your patch. I have problems with compiling due to other
> > > > patches in the queue. I will fix that and recommend it as patch for
> > > > 2.6.38.
> > > 
> > > What do you mean by this?  It applies just fine to my tree, so why
> > > can't I take it now?
> > 
> > If you want then do so, but the stuff in batman-adv's master must be
> > fixed so they have to apply the v3 version of the patch and not the v2
> > version Andy sent.
> 
> That's one of the problems with having an out-of-tree tree.  Please
> don't do that at all anymore.

I don't see a difference in a in-tree tree and and out-of-tree tree when 
applying patches somewhere else out of order. In both situations we have a 
merge conflict (not that the scm says "omg, i cannot merge it" but that the 
thing doesn't compile after the merge). Not that it would care much that there 
is a merge conflict - it only has to be resolved one way or the other. And I 
don't force the submitter to do it (I couldn't do it anyway), but try to help 
to resolve it for the actual maintainer.

I always thought that even when the source is in the kernel (or in staging) 
that there are still a maintainer responsible for it. That this person has to 
go through the patches and look if they do whatever they claim to do and that 
this isn't against what the original implementation had to do or should do.

In case of batman-adv those maintainers are called by the names Marek Lindner 
and Simon Wunderlich. None of those names sound like GregKH or random guy (aka 
me). I know that you are the staging maintainer and you have more to say, but 
wouldn't it be more healthy that the guys who know more details about it can 
take a look at the non critical stuff?

And the only reason I proposed (not forced, only recommended) that will be 
send later for inclusion in 2.6.38 was that you told us that the day a new 
kernel (2.6.36) gets released is too late to get new stuff (other than fixes) 
in your tree for 2.6.37.

> I'll go apply this patch to mine, and you can handle any merge issues if
> you continue to wish to keep an external tree (hint, I STRONGLY
> recommend that you do not, for these reasons and many others.)

The development of batman-adv is mainly done by people which need it 
externally - so out of kernel. That means if we are not allowed anymore to 
have some kind of external tree that we can use, it must be done the other way 
around aka compat-wireless like and without the ability to test experimental 
stuff with the community unless by sending it to you and reverting it before a 
new linux release is made. Otherwise we would only have a external tree which 
is in another form (quilt, loose patches, ...) and would be nothing different 
than what we have currently.

The current way is not to say that we come first, but to keep things 
organized. Take for example Andy's patch - it was in my own opinion to late 
for 2.6.37 and it was nothing real critical (but nevertheless quite helpful). 
So queuing it up with the stuff for 2.6.38 seemed to be a good idea. In that 
time also the affected other code parts could be fixed by the actual author 
and everything flows back to you as a complete package.

And in my own opinion the external tree was quite helpful to see incorrect 
merge resolutions...

Everything above is my own opinion and does not strictly reflect the positions 
and policies of the batman-adv project or the actual maintainers.

thanks,
	Sven

Attachment: signature.asc
Description: This is a digitally signed message part.