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