linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Albert Herranz <albert_herranz@yahoo.es>
To: Michael Buesch <mb@bu3sch.de>
Cc: bcm43xx-dev@lists.berlios.de, linux-netdev@vger.kernel.org,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: b43: do not stack-allocate pio rx/tx header and tail buffers
Date: Fri, 09 Oct 2009 20:52:46 +0200	[thread overview]
Message-ID: <4ACF867E.5000006@yahoo.es> (raw)
In-Reply-To: <200910092005.59916.mb@bu3sch.de>

Michael Buesch wrote:
>> 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.

The patch got elaborated and discussed publicly (successfully or not) by following your instructions.

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

We all sure had a communication issue here.

What you thought it was an (implicit) NAK for the _initial_ version of the patch, others took that as "fix-those-concerns-and-its-fine".
And the expressed concerns where addressed later in the merged patch, sub-optimally (not crappily).

Looking at your new "[PATCH] b43: Optimize PIO scratchbuffer usage" to address the changes introduced by the merged patch, the merged solution is not that _blatantly_ far from your solution.
The patch would have probably got there in one iteration if you have had the chance again to express your new concerns about v2.

I'm sure we can avoid this in the future by being a bit more explicit.

Thanks,
Albert


      reply	other threads:[~2009-10-09 18:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-06 16:20 [PATCH] b43: do not stack-allocate pio rx/tx header buffers Albert Herranz
2009-10-06 20:52 ` Michael Buesch
2009-10-06 21:13   ` John W. Linville
2009-10-06 22:07   ` [PATCH v2] b43: do not stack-allocate pio rx/tx header and tail buffers Albert Herranz
2009-10-07 16:43     ` Larry Finger
2009-10-07 16:57       ` Albert Herranz
2009-10-07 18:01         ` Larry Finger
2009-10-09 17:46           ` b43: do not stack-allocate pio rx/tx header and tail buffers (was: pull request: wireless-2.6 2009-10-08) Albert Herranz
2009-10-09 18:05             ` Michael Buesch
2009-10-09 18:52               ` Albert Herranz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ACF867E.5000006@yahoo.es \
    --to=albert_herranz@yahoo.es \
    --cc=bcm43xx-dev@lists.berlios.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-netdev@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mb@bu3sch.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).