On Thu, Feb 03, 2011 at 11:36:27PM -0800, Luis R. Rodriguez wrote: > Adding Greg for real this time. > > Luis > > On Thu, Feb 3, 2011 at 11:36 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote: > > On Thu, Feb 3, 2011 at 10:23 PM, Vivek Natarajan <vnatarajan@xxxxxxxxxxx> wrote: > >> In a highly noisy environment, a data frame which is queued before > >> a nullfunc frame on a different hw queue may be sent over the air > >> after the tx completion of nullfunc frame. This causes the station > >> to enter power save and the AP to see the station as awake and > >> continues to send the data traffic. Fix this by draining all tx > >> queues before we send the null function frame with PM bit set. > >> > >> Signed-off-by: Vivek Natarajan <vnatarajan@xxxxxxxxxxx> > > > > Hm nice, this is a good example of one of those random not-so-critical > > but still nice fixes which I wish would go to stable. John, Greg, any > > qualms for such things to go to stable if they apply? It was my > > impression we could send it, but I want to verify with both you guys > > so neither we or John get bashed if we try to send it as a stable fix. I think the feeling is that it is silly to mark something for stable if it is not important enough to be sent as a fix for the current release. The standard for being sent for the current release seems to vary a bit between different maintainers, the particular release (i.e. how grumpy is Linus), and the point of the release cycle (i.e. loser at -rc1, tighter at -rc6). But for the most part, to go to the current release it needs to fix a bug rather than adding a feature. The strictest definitions of "bug" include crashes, data corrupters, and some (or possibly all) regressions. As usual, judging bug "worthiness" is a bit of a judgment call. All that said, I think the question is what grey area exists for something that arrives late in the current release cycle but that might still be viewed as a (minor) bug fix? John -- John W. Linville Someday the world will need a hero, and you linville@xxxxxxxxxxxxx might be all we have. Be ready. -- 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
