From: Felipe Contreras <felipe.contreras@gmail.com> To: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org>, Greg KH <gregkh@linuxfoundation.org>, Sergio Correia <lists@uece.net>, linux-kernel@vger.kernel.org, stable@vger.kernel.org, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, linux-wireless Mailing List <linux-wireless@vger.kernel.org>, Sujith Manoharan <c_manoha@qca.qualcomm.com>, "ath9k-devel@lists.ath9k.org" <ath9k-devel@venema.h4ckr.net>, "John W. Linville" <linville@tuxdriver.com> Subject: Re: [ 00/78] 3.3.2-stable review Date: Sun, 15 Apr 2012 20:15:23 +0300 [thread overview] Message-ID: <CAMP44s3mOsCGG5_gd6zTUeXewTFKeVEmAkt2FvM=wTm-5AEC+w@mail.gmail.com> (raw) In-Reply-To: <20120415065124.GC29563@gmail.com> On Sun, Apr 15, 2012 at 9:51 AM, Ingo Molnar <mingo@kernel.org> wrote: > > * Felipe Contreras <felipe.contreras@gmail.com> wrote: >> You are avoiding the argument you replying to; yesterday a >> patch was droppable from the stable review queue, but today, >> after the release, now we *need* it to stay there until it's >> fixed in the mainline. What changed? > > What changed: the stable kernel was released and a new cycle > started. This is not a reason, this is just stating what happens without explaining *why*. Q: What changes when a tag is made? A: A tag is made > If something is broken in -stable it needs to be reverted upstream. Full stop. And now you are describing the rule, without explaining the reason. >> What makes a patch droppable yesterday, but dependent on >> mainline today? > > Time and version release engineering: once a stable kernel is > released any temporary integration testing results are flushed - Yeah, but *why*? *Why* flush the testing results? > the upstream kernel is where we maintain the information of > which patch is broken and which not. Sure, but that has nothing to do with the difference between today and yesterday; both patches come from upstream. In both cases upstream needs to be fixed. > This memory-less process, amongst other things, helps the *next* > major stable kernel become more robust, as it removes the > possibility for version skew between stable and upstream. If you keep the broken patch from yesterday (which is also from upstream) and push it into the release, wouldn't that reduce the version skew between stable and upstream as well? Why is it that the patch from yesterday doesn't reduce the version skew, but the patch from today does? You are not explaining *why*. > If you want a revert you either need to report your problem fast > enough to be caught in -stable integration testing, or you need > to work with upstream to push the fix through properly. And now you are assuming your assumption is right, and go right onto the conclusion. > People explained this to you, again and again, you refused to > listen, repeatedly, again and again. There does not appear to be > any rational set of arguments that will make you admit that you > were wrong about this. I'm sure if I try to argue rationally why hunting is bad with hunters, they'll say I've refused to listen to all their rational set of arguments. It's impossible that you are not explaining the *reason* (there is none), it's impossible that you are being affected by herd mentality, overconfidence, and confirmation bias. No, it cannot be any of those things. > Anyway, in this discussion you have demonstrated it again why > you are one of the very few commenters I had to permanently > block on G+ ... Please, I provided irrefutable evidence for my argument, and I said I would stop if you wanted me to, nobody forced you to continue the discussion. You still blocked me even though you could have asked me not to reply. I can stop the discussion, I told so to Linus Torvalds on G+, if I'm told so. I guess that would make you happy, but that doesn't mean you are right. You are tip-toeing around the question and *never* giving a real reason for why the patch from yesterday is different from the one today. It's like I'm asking why the freezer area is different from the normal refrigerator area, and you are saying; well it's colder, it's usually smaller, and it makes all food taste better. So you are either just describing the differences without explaining the reason (being colder helps for some foods), or you are providing an unsubstantiated claim; you go from a) it's colder, to b) it makes all food taste better. And when asked *why* again, you repeat, well, because it's colder. And then you immediately go to the conclusion; therefore you should put as much food in the freezer as possible. Of course you would think all your answers are obvious and reasonable, what else would you think? You, like everybody else (including me), has a bias blind spot. The fact of the matter is that there's *no reason* why the patch from yesterday can be dropped, and the patch today can't. A tag was made, but it doesn't change the nature of the patch; either way the patch is bad, either way the patch is still in upstream. You assume (correctly) that by keeping it in the stable branch, it would guarantee it will be fixed in upstream sooner, but do we *need* this guarantee? Would you buy a total guarantee for your house, if it costs as much as the house itself? No, you need to look at the costs, and the likelihood of the event you are guaranteeing against happening, not just go "Oh!, guarantee! gimme!". The fact is that without this guarantee, the fix will happen in a reasonable time in upstream anyway. People have explained that in the past there have been situations where fixes are lost, but that's an entirely different situation (..v3.3), we are talking about stable reverts (v3.3...v3.3.1), I challenged David Miller to find evidence for this *ever* happening, and of course I didn't receive any answer. So no, there's no evidence for that happening, you just think it will, let alone how often will that be. You are making these patches guilty by association. Plus, as I argued, somehow the 10000 of patches in queue for the next stable release don't need this guarantee, so what's so bad about making the patch from today one more of them? And even more, even supposing we want this guarantee for the patch from today, that doesn't explain why we don't want it from the patch from yesterday. Again, this difference has *never* been explained. You keep explaining why we want the guarantee, but never explain we why don't want/need it for the patch from yesterday. So you say bad patch should obviously not make it into stable: Ingo: "if a -stable commit does not even apply or does not even boot on Greg's box or on the handful of boxes that test stable release candidates then it obviously cannot become part of the -stable queue." And when asking why not get the same guarantee for the bad patch from yesterday: Stefan: "That would be even sillier than the discussion which we are having." When pressed about why it's sillier for the yesterday patch, but not from today, Stefan Richter didn't reply, of course. You are backed into a corner, you can't provide a good reason why you treat them differently, so you are either going to keep describing the difference, or you are going to keep explaining why the guarantee is good, but not why B needs it, and A doesn't; because you don't have a reason. And when backed into a corner you are going to do what everybody does, not stop for a second, and think deeply about the difference, but you are going to use your bias blind spot, and assume that of course you are right, and of course you are being reasonable, and of course your arguments are flawless, and there's no more reason to discuss. Accepting the possibility that there's no good reason for the different treatment is not an option, of course, that would mean you were wrong, and you can't. FTR. I accept I might be wrong, and there's a good reason for this different treatment, but I haven't seen any. Cheers. -- Felipe Contreras
WARNING: multiple messages have this Message-ID (diff)
From: Felipe Contreras <felipe.contreras@gmail.com> To: ath9k-devel@lists.ath9k.org Subject: [ath9k-devel] [ 00/78] 3.3.2-stable review Date: Sun, 15 Apr 2012 20:15:23 +0300 [thread overview] Message-ID: <CAMP44s3mOsCGG5_gd6zTUeXewTFKeVEmAkt2FvM=wTm-5AEC+w@mail.gmail.com> (raw) In-Reply-To: <20120415065124.GC29563@gmail.com> On Sun, Apr 15, 2012 at 9:51 AM, Ingo Molnar <mingo@kernel.org> wrote: > > * Felipe Contreras <felipe.contreras@gmail.com> wrote: >> You are avoiding the argument you replying to; yesterday a >> patch was droppable from the stable review queue, but today, >> after the release, now we *need* it to stay there until it's >> fixed in the mainline. What changed? > > What changed: the stable kernel was released and a new cycle > started. This is not a reason, this is just stating what happens without explaining *why*. Q: What changes when a tag is made? A: A tag is made > If something is broken in -stable it needs to be reverted upstream. Full stop. And now you are describing the rule, without explaining the reason. >> What makes a patch droppable yesterday, but dependent on >> mainline today? > > Time and version release engineering: once a stable kernel is > released any temporary integration testing results are flushed - Yeah, but *why*? *Why* flush the testing results? > the upstream kernel is where we maintain the information of > which patch is broken and which not. Sure, but that has nothing to do with the difference between today and yesterday; both patches come from upstream. In both cases upstream needs to be fixed. > This memory-less process, amongst other things, helps the *next* > major stable kernel become more robust, as it removes the > possibility for version skew between stable and upstream. If you keep the broken patch from yesterday (which is also from upstream) and push it into the release, wouldn't that reduce the version skew between stable and upstream as well? Why is it that the patch from yesterday doesn't reduce the version skew, but the patch from today does? You are not explaining *why*. > If you want a revert you either need to report your problem fast > enough to be caught in -stable integration testing, or you need > to work with upstream to push the fix through properly. And now you are assuming your assumption is right, and go right onto the conclusion. > People explained this to you, again and again, you refused to > listen, repeatedly, again and again. There does not appear to be > any rational set of arguments that will make you admit that you > were wrong about this. I'm sure if I try to argue rationally why hunting is bad with hunters, they'll say I've refused to listen to all their rational set of arguments. It's impossible that you are not explaining the *reason* (there is none), it's impossible that you are being affected by herd mentality, overconfidence, and confirmation bias. No, it cannot be any of those things. > Anyway, in this discussion you have demonstrated it again why > you are one of the very few commenters I had to permanently > block on G+ ... Please, I provided irrefutable evidence for my argument, and I said I would stop if you wanted me to, nobody forced you to continue the discussion. You still blocked me even though you could have asked me not to reply. I can stop the discussion, I told so to Linus Torvalds on G+, if I'm told so. I guess that would make you happy, but that doesn't mean you are right. You are tip-toeing around the question and *never* giving a real reason for why the patch from yesterday is different from the one today. It's like I'm asking why the freezer area is different from the normal refrigerator area, and you are saying; well it's colder, it's usually smaller, and it makes all food taste better. So you are either just describing the differences without explaining the reason (being colder helps for some foods), or you are providing an unsubstantiated claim; you go from a) it's colder, to b) it makes all food taste better. And when asked *why* again, you repeat, well, because it's colder. And then you immediately go to the conclusion; therefore you should put as much food in the freezer as possible. Of course you would think all your answers are obvious and reasonable, what else would you think? You, like everybody else (including me), has a bias blind spot. The fact of the matter is that there's *no reason* why the patch from yesterday can be dropped, and the patch today can't. A tag was made, but it doesn't change the nature of the patch; either way the patch is bad, either way the patch is still in upstream. You assume (correctly) that by keeping it in the stable branch, it would guarantee it will be fixed in upstream sooner, but do we *need* this guarantee? Would you buy a total guarantee for your house, if it costs as much as the house itself? No, you need to look at the costs, and the likelihood of the event you are guaranteeing against happening, not just go "Oh!, guarantee! gimme!". The fact is that without this guarantee, the fix will happen in a reasonable time in upstream anyway. People have explained that in the past there have been situations where fixes are lost, but that's an entirely different situation (..v3.3), we are talking about stable reverts (v3.3...v3.3.1), I challenged David Miller to find evidence for this *ever* happening, and of course I didn't receive any answer. So no, there's no evidence for that happening, you just think it will, let alone how often will that be. You are making these patches guilty by association. Plus, as I argued, somehow the 10000 of patches in queue for the next stable release don't need this guarantee, so what's so bad about making the patch from today one more of them? And even more, even supposing we want this guarantee for the patch from today, that doesn't explain why we don't want it from the patch from yesterday. Again, this difference has *never* been explained. You keep explaining why we want the guarantee, but never explain we why don't want/need it for the patch from yesterday. So you say bad patch should obviously not make it into stable: Ingo: "if a -stable commit does not even apply or does not even boot on Greg's box or on the handful of boxes that test stable release candidates then it obviously cannot become part of the -stable queue." And when asking why not get the same guarantee for the bad patch from yesterday: Stefan: "That would be even sillier than the discussion which we are having." When pressed about why it's sillier for the yesterday patch, but not from today, Stefan Richter didn't reply, of course. You are backed into a corner, you can't provide a good reason why you treat them differently, so you are either going to keep describing the difference, or you are going to keep explaining why the guarantee is good, but not why B needs it, and A doesn't; because you don't have a reason. And when backed into a corner you are going to do what everybody does, not stop for a second, and think deeply about the difference, but you are going to use your bias blind spot, and assume that of course you are right, and of course you are being reasonable, and of course your arguments are flawless, and there's no more reason to discuss. Accepting the possibility that there's no good reason for the different treatment is not an option, of course, that would mean you were wrong, and you can't. FTR. I accept I might be wrong, and there's a good reason for this different treatment, but I haven't seen any. Cheers. -- Felipe Contreras
next prev parent reply other threads:[~2012-04-15 17:15 UTC|newest] Thread overview: 270+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-04-11 23:11 [ 00/78] 3.3.2-stable review Greg KH 2012-04-11 23:10 ` [ 01/78] x86 bpf_jit: fix a bug in emitting the 16-bit immediate operand of AND Greg KH 2012-04-11 23:10 ` [ 02/78] via-rhine: fix wait-bit inversion Greg KH 2012-04-11 23:10 ` [ 03/78] tg3: Fix 5717 serdes powerdown problem Greg KH 2012-04-11 23:10 ` [ 04/78] sky2: dont overwrite settings for PHY Quick link Greg KH 2012-04-11 23:10 ` [ 05/78] rose_dev: fix memcpy-bug in rose_set_mac_address Greg KH 2012-04-11 23:10 ` [ 06/78] net: usb: cdc_eem: fix mtu Greg KH 2012-04-11 23:10 ` [ 07/78] Fix non TBI PHY access; a bad merge undid bug fix in a previous commit Greg KH 2012-04-11 23:10 ` [ 08/78] ALSA: hda/realtek - Fix ADC assignment with a shared HP/Mic pin Greg KH 2012-04-11 23:10 ` [ 09/78] ASoC: wm8994: Update WM8994 DCS calibration Greg KH 2012-04-11 23:10 ` [ 10/78] mtd: ixp4xx: oops in ixp4xx_flash_probe Greg KH 2012-04-11 23:10 ` [ 11/78] mtd: mips: lantiq: reintroduce support for cmdline partitions Greg KH 2012-04-11 23:10 ` [ 12/78] mtd: nand: gpmi: use correct member for checking NAND_BBT_USE_FLASH Greg KH 2012-04-11 23:10 ` [ 13/78] mtd: sst25l: initialize writebufsize Greg KH 2012-04-11 23:10 ` [ 14/78] mtd: doc2001plus: " Greg KH 2012-04-11 23:10 ` [ 15/78] mtd: doc2000: " Greg KH 2012-04-11 23:10 ` [ 16/78] mtd: doc2001: " Greg KH 2012-04-11 23:10 ` [ 17/78] mtd: docg3: " Greg KH 2012-04-11 23:10 ` [ 18/78] mtd: block2mtd: " Greg KH 2012-04-11 23:10 ` [ 19/78] mtd: lart: " Greg KH 2012-04-11 23:10 ` [ 20/78] mtd: m25p80: set writebufsize Greg KH 2012-04-11 23:10 ` [ 21/78] ACPI: Do cpufreq clamping for throttling per package v2 Greg KH 2012-04-11 23:10 ` [ 22/78] PNPACPI: Fix device ref leaking in acpi_pnp_match Greg KH 2012-04-11 23:10 ` [ 23/78] ACPICA: Fix regression in FADT revision checks Greg KH 2012-04-11 23:10 ` [ 24/78] modpost: fix ALL_INIT_DATA_SECTIONS Greg KH 2012-04-11 23:10 ` [ 25/78] genirq: Adjust irq thread affinity on IRQ_SET_MASK_OK_NOCOPY return value Greg KH 2012-04-11 23:10 ` [ 26/78] tracing: Fix ftrace stack trace entries Greg KH 2012-04-11 23:10 ` [ 27/78] tracing: Fix ent_size in trace output Greg KH 2012-04-11 23:10 ` [ 28/78] m68k/mac: Add missing platform check before registering platform devices Greg KH 2012-04-11 23:10 ` [ 29/78] mac80211: fix possible tid_rx->reorder_timer use after free Greg KH 2012-04-11 23:10 ` [ 30/78] rtlwifi: rtl8192ce: rtl8192cu: rtl8192de: Fix low-gain setting when scanning Greg KH 2012-04-11 23:10 ` [ 31/78] ath9k: fix max noise floor threshold Greg KH 2012-04-14 5:36 ` Ben Hutchings 2012-04-14 6:26 ` Rajkumar Manoharan 2012-04-11 23:10 ` [ 32/78] drm: Validate requested virtual size against allocated fb size Greg KH 2012-04-11 23:10 ` [ 33/78] drm/radeon/kms: fix fans after resume Greg KH 2012-04-11 23:10 ` [ 34/78] drm/i915: no-lvds quirk on MSI DC500 Greg KH 2012-04-11 23:10 ` [ 35/78] drm/i915: treat src w & h as fixed point in sprite handling code Greg KH 2012-04-11 23:10 ` [ 36/78] drm/i915: Sanitize BIOS debugging bits from PIPECONF Greg KH 2012-04-11 23:10 ` [ 37/78] drm/i915: Add lock on drm_helper_resume_force_mode Greg KH 2012-04-11 23:10 ` [ 38/78] drm/i915: quirk away broken OpRegion VBT Greg KH 2012-04-11 23:10 ` [ 39/78] firmware_class: Rework usermodehelper check Greg KH 2012-04-11 23:10 ` [ 40/78] firmware_class: Split _request_firmware() into three functions, v2 Greg KH 2012-04-11 23:10 ` [ 41/78] firmware_class: Do not warn that system is not ready from async loads Greg KH 2012-04-11 23:11 ` [ 42/78] PM / Runtime: dont forget to wake up waitqueue on failure Greg KH 2012-04-14 5:23 ` Ben Hutchings 2012-04-11 23:11 ` [ 43/78] PM / Hibernate: Disable usermode helpers right before freezing tasks Greg KH 2012-04-11 23:11 ` [ 44/78] PM / Sleep: Move disabling of usermode helpers to the freezer Greg KH 2012-04-11 23:11 ` [ 45/78] PM / Sleep: Mitigate race between the freezer and request_firmware() Greg KH 2012-04-11 23:11 ` [ 46/78] kgdb,debug_core: pass the breakpoint struct instead of address and memory Greg KH 2012-04-11 23:11 ` [ 47/78] kgdbts: Fix kernel oops with CONFIG_DEBUG_RODATA Greg KH 2012-04-11 23:11 ` [ 48/78] kgdbts: (1 of 2) fix single step awareness to work correctly with SMP Greg KH 2012-04-11 23:11 ` [ 49/78] kgdbts: (2 " Greg KH 2012-04-11 23:11 ` [ 50/78] x86,kgdb: Fix DEBUG_RODATA limitation using text_poke() Greg KH 2012-04-11 23:11 ` [ 51/78] CIFS: Fix VFS lock usage for oplocked files Greg KH 2012-04-11 23:11 ` [ 52/78] USB: ohci-at91: fix vbus_pin_active_low handling Greg KH 2012-04-11 23:11 ` [ 53/78] ARM: at91/USB host: specify and handle properly vbus_pin_active_low Greg KH 2012-04-11 23:11 ` [ 54/78] mmc: sdio: Use empty system suspend/resume callbacks at the bus level Greg KH 2012-04-11 23:11 ` [ 55/78] mmc: sdhci-dove: Fix compile error by including module.h Greg KH 2012-04-11 23:11 ` [ 56/78] mmc: atmel-mci: correct data timeout computation Greg KH 2012-04-11 23:11 ` [ 57/78] tcm_fc: Add abort flag for gracefully handling exchange timeout Greg KH 2012-04-11 23:11 ` [ 58/78] tcm_fc: Do not free tpg structure during wq allocation failure Greg KH 2012-04-11 23:11 ` [ 59/78] sysctl: fix write access to dmesg_restrict/kptr_restrict Greg KH 2012-04-11 23:11 ` [ 60/78] regmap: prevent division by zero in rbtree_show Greg KH 2012-04-11 23:11 ` [ 61/78] modpost: Fix modpost license checking of vmlinux.o Greg KH 2012-04-11 23:11 ` [ 62/78] mfd: Fix section mismatch warning for da9052-spi Greg KH 2012-04-11 23:11 ` [ 63/78] android, lowmemorykiller: remove task handoff notifier Greg KH 2012-04-11 23:11 ` [ 64/78] TOMOYO: Fix mount flags checking order Greg KH 2012-04-11 23:11 ` [ 65/78] iwlegacy: do not nulify il->vif on reset Greg KH 2012-04-11 23:11 ` [ 66/78] Revert "x86/ioapic: Add register level checks to detect bogus io-apic entries" Greg KH 2012-04-11 23:11 ` [ 67/78] acer-wmi: No wifi rfkill on Sony machines Greg KH 2012-04-11 23:11 ` [ 68/78] Fix length of buffer copied in __nfs4_get_acl_uncached Greg KH 2012-04-11 23:11 ` [ 69/78] sched/x86: Fix overflow in cyc2ns_offset Greg KH 2012-04-11 23:11 ` [ 70/78] mfd: Clear twl6030 IRQ status register only once Greg KH 2012-04-11 23:11 ` [ 71/78] USB: Add Motorola Rokr E6 Id to the USBNet driver "zaurus" Greg KH 2012-04-11 23:11 ` [ 72/78] ioat: fix size of completion for Xen Greg KH 2012-04-11 23:11 ` [ 73/78] [media] uvcvideo: Fix race-related crash in uvc_video_clock_update() Greg KH 2012-04-11 23:11 ` [ 74/78] ASoC: ak4642: fixup: mute needs +1 step Greg KH 2012-04-11 23:11 ` [ 75/78] ASoC: tegra: fix i2s compilation when !CONFIG_DEBUG_FS Greg KH 2012-04-11 23:11 ` [ 76/78] media: dvb_frontend: regression fix: userspace ABI broken for xine Greg KH 2012-04-11 23:11 ` [ 77/78] media: dvb-core: fix DVBFE_ALGO_HW retune bug Greg KH 2012-04-11 23:11 ` [ 78/78] cred: copy_process() should clear child->replacement_session_keyring Greg KH 2012-04-11 23:59 ` [ 00/78] 3.3.2-stable review Sergio Correia 2012-04-11 23:59 ` [ath9k-devel] " Sergio Correia 2012-04-11 23:59 ` Sergio Correia 2012-04-11 23:59 ` Sergio Correia 2012-04-12 0:29 ` Greg KH 2012-04-12 0:29 ` [ath9k-devel] " Greg KH 2012-04-12 0:29 ` Greg KH 2012-04-12 0:57 ` Sergio Correia 2012-04-12 0:57 ` [ath9k-devel] " Sergio Correia 2012-04-12 0:57 ` Sergio Correia 2012-04-12 1:03 ` Felipe Contreras 2012-04-12 1:03 ` [ath9k-devel] " Felipe Contreras 2012-04-12 1:13 ` Greg KH 2012-04-12 1:13 ` [ath9k-devel] " Greg KH 2012-04-12 1:13 ` Greg KH 2012-04-12 13:32 ` Felipe Contreras 2012-04-12 13:32 ` [ath9k-devel] " Felipe Contreras 2012-04-12 14:46 ` Greg KH 2012-04-12 14:46 ` [ath9k-devel] " Greg KH 2012-04-12 14:46 ` Greg KH 2012-04-12 16:49 ` Felipe Contreras 2012-04-12 16:49 ` [ath9k-devel] " Felipe Contreras 2012-04-12 17:24 ` Adrian Chadd 2012-04-12 17:24 ` [ath9k-devel] " Adrian Chadd 2012-04-12 17:24 ` Adrian Chadd 2012-04-12 18:43 ` Felipe Contreras 2012-04-12 18:43 ` [ath9k-devel] " Felipe Contreras 2012-04-12 18:56 ` Jonathan Nieder 2012-04-12 18:56 ` [ath9k-devel] " Jonathan Nieder 2012-04-12 21:34 ` Felipe Contreras 2012-04-12 21:34 ` [ath9k-devel] " Felipe Contreras 2012-04-12 21:43 ` Willy Tarreau 2012-04-12 21:43 ` [ath9k-devel] " Willy Tarreau 2012-04-12 20:07 ` Greg KH 2012-04-12 20:07 ` [ath9k-devel] " Greg KH 2012-04-12 20:07 ` Greg KH 2012-04-12 20:52 ` Sven-Haegar Koch 2012-04-12 20:52 ` [ath9k-devel] " Sven-Haegar Koch 2012-04-13 8:57 ` Stefan Richter 2012-04-13 8:57 ` [ath9k-devel] " Stefan Richter 2012-04-13 10:29 ` Felipe Contreras 2012-04-13 10:29 ` [ath9k-devel] " Felipe Contreras 2012-04-13 13:42 ` Stefan Richter 2012-04-13 13:42 ` [ath9k-devel] " Stefan Richter 2012-04-13 14:01 ` Stefan Richter 2012-04-13 14:01 ` [ath9k-devel] " Stefan Richter 2012-04-13 22:38 ` Felipe Contreras 2012-04-13 22:38 ` [ath9k-devel] " Felipe Contreras 2012-04-13 23:05 ` Jonathan Nieder 2012-04-13 23:05 ` [ath9k-devel] " Jonathan Nieder 2012-04-13 23:18 ` Felipe Contreras 2012-04-13 23:18 ` [ath9k-devel] " Felipe Contreras 2012-04-14 5:44 ` Willy Tarreau 2012-04-14 5:44 ` [ath9k-devel] " Willy Tarreau 2012-04-14 5:44 ` Willy Tarreau 2012-04-14 15:43 ` Felipe Contreras 2012-04-14 15:43 ` [ath9k-devel] " Felipe Contreras 2012-04-14 16:02 ` Willy Tarreau 2012-04-14 16:02 ` [ath9k-devel] " Willy Tarreau 2012-04-14 9:10 ` Stefan Richter 2012-04-14 9:10 ` [ath9k-devel] " Stefan Richter 2012-04-14 15:52 ` Felipe Contreras 2012-04-14 15:52 ` [ath9k-devel] " Felipe Contreras 2012-04-14 18:08 ` Stefan Richter 2012-04-14 18:08 ` [ath9k-devel] " Stefan Richter 2012-04-14 7:41 ` Stefan Richter 2012-04-14 7:41 ` [ath9k-devel] " Stefan Richter 2012-04-14 15:29 ` Felipe Contreras 2012-04-14 15:29 ` [ath9k-devel] " Felipe Contreras 2012-04-14 15:57 ` Willy Tarreau 2012-04-14 15:57 ` [ath9k-devel] " Willy Tarreau 2012-04-14 19:33 ` Felipe Contreras 2012-04-14 19:33 ` [ath9k-devel] " Felipe Contreras 2012-04-14 19:58 ` Willy Tarreau 2012-04-14 19:58 ` [ath9k-devel] " Willy Tarreau 2012-04-14 17:55 ` Stefan Richter 2012-04-14 17:55 ` [ath9k-devel] " Stefan Richter 2012-04-14 19:21 ` Felipe Contreras 2012-04-14 19:21 ` [ath9k-devel] " Felipe Contreras 2012-04-14 21:21 ` Stefan Richter 2012-04-14 21:21 ` [ath9k-devel] " Stefan Richter 2012-04-14 22:09 ` Felipe Contreras 2012-04-14 22:09 ` [ath9k-devel] " Felipe Contreras 2012-04-14 22:47 ` Stefan Richter 2012-04-14 22:47 ` [ath9k-devel] " Stefan Richter 2012-04-14 22:56 ` Felipe Contreras 2012-04-14 22:56 ` [ath9k-devel] " Felipe Contreras 2012-04-14 23:06 ` Adrian Chadd 2012-04-14 23:06 ` [ath9k-devel] " Adrian Chadd 2012-04-13 19:08 ` Peter Stuge 2012-04-13 19:08 ` Peter Stuge 2012-04-13 22:53 ` Felipe Contreras 2012-04-13 22:53 ` Felipe Contreras 2012-04-14 6:01 ` Willy Tarreau 2012-04-14 6:01 ` Willy Tarreau 2012-04-16 16:27 ` Greg KH 2012-04-16 16:27 ` Greg KH 2012-04-16 20:11 ` Felipe Contreras 2012-04-16 20:11 ` Felipe Contreras 2012-04-16 20:58 ` Greg KH 2012-04-16 20:58 ` Greg KH 2012-04-16 20:58 ` Greg KH 2012-04-16 21:18 ` Felipe Contreras 2012-04-16 21:18 ` Felipe Contreras 2012-04-16 21:27 ` Greg KH 2012-04-16 21:27 ` Greg KH 2012-04-16 21:27 ` Greg KH 2012-04-16 21:44 ` Felipe Contreras 2012-04-16 21:44 ` Felipe Contreras 2012-04-16 22:34 ` Peter Stuge 2012-04-16 22:34 ` Peter Stuge 2012-04-17 5:24 ` Willy Tarreau 2012-04-17 5:24 ` Willy Tarreau 2012-04-17 5:24 ` Willy Tarreau 2012-04-16 21:50 ` Felipe Contreras 2012-04-16 21:50 ` Felipe Contreras 2012-04-16 21:54 ` Don deJuan 2012-04-16 21:54 ` Don deJuan 2012-04-16 22:02 ` Don deJuan 2012-04-16 22:02 ` Don deJuan 2012-04-16 21:39 ` Don deJuan 2012-04-16 21:39 ` Don deJuan 2012-04-12 18:40 ` Willy Tarreau 2012-04-12 18:40 ` [ath9k-devel] " Willy Tarreau 2012-04-12 18:40 ` Willy Tarreau 2012-04-12 19:05 ` Linus Torvalds 2012-04-12 19:05 ` [ath9k-devel] " Linus Torvalds 2012-04-12 19:05 ` Linus Torvalds 2012-04-12 21:20 ` Felipe Contreras 2012-04-12 21:20 ` [ath9k-devel] " Felipe Contreras 2012-04-12 21:34 ` Linus Torvalds 2012-04-12 21:34 ` [ath9k-devel] " Linus Torvalds 2012-04-12 21:44 ` Linus Torvalds 2012-04-12 21:44 ` [ath9k-devel] " Linus Torvalds 2012-04-12 22:02 ` Luis R. Rodriguez 2012-04-12 22:02 ` Luis R. Rodriguez 2012-04-12 22:04 ` Felipe Contreras 2012-04-12 22:04 ` [ath9k-devel] " Felipe Contreras 2012-04-12 22:07 ` Linus Torvalds 2012-04-12 22:07 ` [ath9k-devel] " Linus Torvalds 2012-04-12 22:29 ` Felipe Contreras 2012-04-12 22:29 ` [ath9k-devel] " Felipe Contreras 2012-04-14 10:47 ` Ingo Molnar 2012-04-14 10:47 ` [ath9k-devel] " Ingo Molnar 2012-04-14 15:59 ` Felipe Contreras 2012-04-14 15:59 ` [ath9k-devel] " Felipe Contreras 2012-04-15 6:51 ` Ingo Molnar 2012-04-15 6:51 ` [ath9k-devel] " Ingo Molnar 2012-04-15 17:15 ` Felipe Contreras [this message] 2012-04-15 17:15 ` Felipe Contreras 2012-04-15 17:29 ` Willy Tarreau 2012-04-15 17:29 ` [ath9k-devel] " Willy Tarreau 2012-04-15 17:49 ` Linus Torvalds 2012-04-15 17:49 ` [ath9k-devel] " Linus Torvalds 2012-04-15 22:12 ` Felipe Contreras 2012-04-15 22:12 ` [ath9k-devel] " Felipe Contreras 2012-04-16 5:32 ` Ingo Molnar 2012-04-16 5:32 ` [ath9k-devel] " Ingo Molnar 2012-04-16 20:25 ` Felipe Contreras 2012-04-16 20:25 ` [ath9k-devel] " Felipe Contreras 2012-04-16 21:08 ` Arend van Spriel 2012-04-16 21:08 ` [ath9k-devel] " Arend van Spriel 2012-04-16 5:39 ` Willy Tarreau 2012-04-16 5:39 ` [ath9k-devel] " Willy Tarreau 2012-04-16 6:38 ` Ingo Molnar 2012-04-16 6:38 ` [ath9k-devel] " Ingo Molnar 2012-04-12 22:12 ` David Miller 2012-04-12 22:12 ` [ath9k-devel] " David Miller 2012-04-12 22:58 ` Felipe Contreras 2012-04-12 22:58 ` [ath9k-devel] " Felipe Contreras 2012-04-13 5:34 ` Willy Tarreau 2012-04-13 5:34 ` [ath9k-devel] " Willy Tarreau 2012-04-13 10:04 ` Felipe Contreras 2012-04-13 10:04 ` [ath9k-devel] " Felipe Contreras 2012-04-12 21:39 ` Willy Tarreau 2012-04-12 21:39 ` [ath9k-devel] " Willy Tarreau 2012-04-12 22:02 ` Jesper Juhl 2012-04-12 22:02 ` [ath9k-devel] " Jesper Juhl 2012-04-12 19:57 ` Alexander Holler 2012-04-12 19:57 ` [ath9k-devel] " Alexander Holler 2012-04-12 20:06 ` Greg KH 2012-04-12 20:06 ` [ath9k-devel] " Greg KH 2012-04-12 20:30 ` Alexander Holler 2012-04-12 20:30 ` [ath9k-devel] " Alexander Holler 2012-04-12 22:31 ` Greg KH 2012-04-12 22:31 ` [ath9k-devel] " Greg KH 2012-04-12 4:16 ` Heinz Diehl 2012-04-12 4:16 ` [ath9k-devel] " Heinz Diehl
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='CAMP44s3mOsCGG5_gd6zTUeXewTFKeVEmAkt2FvM=wTm-5AEC+w@mail.gmail.com' \ --to=felipe.contreras@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=alan@lxorguk.ukuu.org.uk \ --cc=ath9k-devel@venema.h4ckr.net \ --cc=c_manoha@qca.qualcomm.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=linville@tuxdriver.com \ --cc=lists@uece.net \ --cc=mingo@kernel.org \ --cc=stable@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.