On Friday 09 October 2009 19:46:31 Albert Herranz wrote: > I'm not arguing if the patch should have been immediately merged upstream or not without your ack (I'm probably more on your side here, as the patch was still being discussed on the ML). > The patch [1] may not be up to your quality standards or may not take into account other requirements (that you have not expressed nor on the ML nor on IRC) but I'm sure it's far from being "random", "move crap" or "add stupid comments". That's the unfair part. > > The reason I posted the initial patch for review was because you kind of told me [2]. > > [20:06] <mb_> Anyway, I'm not going to fix this. If you need it fixed, please send patches Yeah, but that doesn't mean that either hack is acceptable. It just means that my time is limited and I added this non-issue (which I still think it is) to the very bottom of my priority list. > After ~22 hours if I'm not mistaken (yes, less than 24...) John, who had previously expressed his intentions to merge the patch [5], picked it for wireless-2.6. > And a day later, more or less again, John did the GIT PULL request. My impression was, that if the maintainer rejects a patch and asks for a new version, the upstream maintainer must not take the patch until the maintainer acked the new version. It seems I was wrong, though. > My point here is that there's no reason for such strong words concerning the quality of the patch code. It's really not that bad for such wording. > I'm sure that if the patch was really crap it would have been immediately NAK'ed by you or by any sane maintainer. It _was_ immediately NAK'ed by me. I did not know that I need to NAK every single new version of a patch explicitely. I thought NAK-ing a patch would put it into some special state that only an explicit ACK could take it out of. -- Greetings, Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
