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. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
