From: Felipe Contreras <felipe.contreras@gmail.com> To: Willy Tarreau <w@1wt.eu> Cc: David Miller <davem@davemloft.net>, torvalds@linux-foundation.org, gregkh@linuxfoundation.org, lists@uece.net, linux-kernel@vger.kernel.org, stable@vger.kernel.org, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, linux-wireless@vger.kernel.org, c_manoha@qca.qualcomm.com, ath9k-devel@venema.h4ckr.net, linville@tuxdriver.com Subject: Re: [ 00/78] 3.3.2-stable review Date: Fri, 13 Apr 2012 13:04:24 +0300 [thread overview] Message-ID: <CAMP44s36PFbo6R1Wa5ZULByOS2qQFad-e6Mavgjv9B3v-oGFoA@mail.gmail.com> (raw) In-Reply-To: <20120413053416.GC12807@1wt.eu> On Fri, Apr 13, 2012 at 8:34 AM, Willy Tarreau <w@1wt.eu> wrote: > On Fri, Apr 13, 2012 at 01:58:10AM +0300, Felipe Contreras wrote: >> On Fri, Apr 13, 2012 at 1:12 AM, David Miller <davem@davemloft.net> wrote: >> > From: Felipe Contreras <felipe.contreras@gmail.com> >> > Date: Fri, 13 Apr 2012 01:04:42 +0300 >> > >> >> Wrong is wrong, before or after the 3.3.1 tag, this patch is not >> >> 'stable' material, and removing it does not affect upstream at all. >> > >> > What you don't understand is that bug fixes will get lost if you only >> > fix them in -stable, it doesn't matter HOW THEY GOT into -stable. >> >> Let's suppose that c1afdaf was never back-ported from v3.4-rc1, how >> would you have fond out there was an issue with it? There's 10000 >> patches in v3.4-rc2, how do you expect to find issues in them? >> >> People found out this issue on v3.4-rc1, so the fix would not have >> been lost, but lets assume it would, v3.3.1 had the issue, the patch >> as reverted in v3.3.2, and v3.4 still had the issue. So what? There's >> already 10000 patches that would never make it to 3.3.x, and many will >> have issues, which is why there would be v3.4.x. >> >> > In fact IT HAS FUCKING HAPPENED that we didn't fix something upstream >> > that got fixed in -stable a time long ago when we didn't have the >> > policy we're using now which you're going so unreasonably ape-shit >> > about. >> >> I see how a *fix* on stable could get lost, but this is not a fix. > > Felipe, you don't seem to get it : there are many bugs in each new release. > Given the number of fixes Greg merges into a longterm branch, I'd say that > there are around 1500 bugs waiting to be discovered and fixed in a new > release. Does this mean we need to fix them all at once ? No, because we > don't know about them yet. > > The process you're criticizing consists in ensuring that once a bug is known, > it gets fixed in mainline so that it never appears there again. The way the > bug is discovered doesn't matter, even if it's discovered that a fix caused > the bug and that it must be reverted. The fact is mainline is buggy and we > know this because stable is too. So mainline must be fixed first. This > process works because stable users are pressuring developers to push their > fixes to Linus in order to get them. What happened with this bug prooved > the process is working fine. Let's list the scenarios: a) normal patch v3.3 (good), v3.4 (+) (good) b) normal stable patch v3.3 (good), v3.3.1 (+) (good), v3.4 (+) (good) c) regression patch v3.3 (good), v3.4 (+) (bad) d) regression patch, fixed v3.3 (good), v3.4 (good) e) stable regression patch v3.3 (good), v3.3.1 (+) (bad), v3.4 (+) (bad) e.1) stable regression patch, normal fix v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.4 (good) e.2) stable regression patch, lost fix v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.4 (+) (bad) As you can see, even in the worst-case scenarios, there's no difference between (c) and (e.2). But what you are saying is that it doesn't matter at which point the issue with the patch is found, (e.2) has to be avoided *at all costs*, but you don't explain _why_. What is so different between (c) and (e.2)? And this is the worst-case scenario, I keep hearing people that this has happened in the past, but I don' think so, I think what has happened is: f) stable patch fix, lost v3.3 (bad), v3.3.1 (+) (good), v3.4 (bad) That I can see happening, and the current rules ensure that would not happen, but (e.2)? I yet have to see any evidence of this happening in the past. But lets be realistic; most likely the issue would be and fixed in upstream (d), so it doesn't matter what happens in stable, the end result would be the same (e.1). In fact in this particular patch people found problems in v3.4-rc1, so all evidence points out that we would have ended up in (e.1), not (e.2). So, if we expand the possibilities in the current situation, we have: 0) v3.3 (good), v3.3.1 (good), v3.3.2 (good), v3.3.3 (good), v3.4 (+) (bad), v3.4.1 (good) 1) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.3.3 (good), v3.4 (good), v3.4.1 (good) 2) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (+) (bad), v3.3.3 (good), v3.4 (good), v3.4.1 (good) 3) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.3.3 (good), v3.4 (+) (bad), v3.4.1 (good) #unlikely 4) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (+) (bad), v3.3.3 (+) (bad), v3.4 (+) (bad), v3.4.1 (good) #unlikely It looks like the patch is going both to upstream and stable (1), which is ideal, but when faced with the option between (2) and (3), you say (3) must absolutely be avoided even though it's basically the same as (0), which is the norm for thousands of patches that don't get back-ported to stable (and it's also unlikely to happen). Why? Plus, (1) (2) (3) (4) are already bad situations, and should be avoided at all costs; patches to stable are not supposed to be potentially dangerous, they are not meant be breaking things. > Another point is that you don't want stable to merge, revert, merge again, > revert again etc... This happened a little bit during 2.6.32 because some > fixes were not really obvious. It's common for some fixes to have to be > adapted for stable branches, and to have side effects, hence the review > cycle. We need to limit these random issues as much as possible if we > don't want users to lose trust in the stable branches. This is extremely > important. So picking random fixes that have not been qualified by all > interested parties in stable is inappropriate. Reverting without evaluating > impacts is one form of picking a random fix. Yeah, but that is not the case here, the options are clear; (a) go back to a previous state where power management doesn't work correctly, (b) stay in the current state where the system goes to a completely unusable state. > What you should have done would have been to reply to Greg saying "wait a > minute, we still have an issue with patch XX, I'm trying to get it reverted > in upstream and will send you the commit ID, it would be nice to have it in > 3.3.2". It wastes less time for everyone and achieves the same result. There's a lot of people affected by this issue, and a lot of noise. Personally I didn't receive the revert patch, so I could not comment on it. I think this patch should have been sent to LKML, but one cannot expect everyone to do the perfect thing all the time. > Once again, if you think that the stable branch you're using is not stable > enough for you, pick another one. Greg maintains multiple branches so that > everyone is satisfied. The risk of bugs over time probably looks like > (cos(t)+1)/t. Find an older branch with a much smaller risk of regressions > and be done with it. I'm not sure I would want to use 'stable' anymore, because clearly, the main goal doesn't seem to be *stability* as I thought. Apparently it's supposed to be a testing ground for patches queued for the next release. > Last point, you should note that you're the only one here who doesn't > understand the process. That doesn't make you a fool, but it should tell you > that you probably need to think a bit further before telling people how they > should work, especially when all other ones agree on the benefits of the > process, including Arnd explaining that FreeBSD had been facing the exact > same trouble and now applies the same process. It is not just a small band > of nerds doing this for fun right here, but seems to be more generalized. Ad populum. The fact that I'm questioning the process doesn't mean I don't understand it. But if you are not open to criticism, fine. 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: Fri, 13 Apr 2012 13:04:24 +0300 [thread overview] Message-ID: <CAMP44s36PFbo6R1Wa5ZULByOS2qQFad-e6Mavgjv9B3v-oGFoA@mail.gmail.com> (raw) In-Reply-To: <20120413053416.GC12807@1wt.eu> On Fri, Apr 13, 2012 at 8:34 AM, Willy Tarreau <w@1wt.eu> wrote: > On Fri, Apr 13, 2012 at 01:58:10AM +0300, Felipe Contreras wrote: >> On Fri, Apr 13, 2012 at 1:12 AM, David Miller <davem@davemloft.net> wrote: >> > From: Felipe Contreras <felipe.contreras@gmail.com> >> > Date: Fri, 13 Apr 2012 01:04:42 +0300 >> > >> >> Wrong is wrong, before or after the 3.3.1 tag, this patch is not >> >> 'stable' material, and removing it does not affect upstream at all. >> > >> > What you don't understand is that bug fixes will get lost if you only >> > fix them in -stable, it doesn't matter HOW THEY GOT into -stable. >> >> Let's suppose that c1afdaf was never back-ported from v3.4-rc1, how >> would you have fond out there was an issue with it? There's 10000 >> patches in v3.4-rc2, how do you expect to find issues in them? >> >> People found out this issue on v3.4-rc1, so the fix would not have >> been lost, but lets assume it would, v3.3.1 had the issue, the patch >> as reverted in v3.3.2, and v3.4 still had the issue. So what? There's >> already 10000 patches that would never make it to 3.3.x, and many will >> have issues, which is why there would be v3.4.x. >> >> > In fact IT HAS FUCKING HAPPENED that we didn't fix something upstream >> > that got fixed in -stable a time long ago when we didn't have the >> > policy we're using now which you're going so unreasonably ape-shit >> > about. >> >> I see how a *fix* on stable could get lost, but this is not a fix. > > Felipe, you don't seem to get it : there are many bugs in each new release. > Given the number of fixes Greg merges into a longterm branch, I'd say that > there are around 1500 bugs waiting to be discovered and fixed in a new > release. Does this mean we need to fix them all at once ? No, because we > don't know about them yet. > > The process you're criticizing consists in ensuring that once a bug is known, > it gets fixed in mainline so that it never appears there again. The way the > bug is discovered doesn't matter, even if it's discovered that a fix caused > the bug and that it must be reverted. The fact is mainline is buggy and we > know this because stable is too. So mainline must be fixed first. This > process works because stable users are pressuring developers to push their > fixes to Linus in order to get them. What happened with this bug prooved > the process is working fine. Let's list the scenarios: a) normal patch v3.3 (good), v3.4 (+) (good) b) normal stable patch v3.3 (good), v3.3.1 (+) (good), v3.4 (+) (good) c) regression patch v3.3 (good), v3.4 (+) (bad) d) regression patch, fixed v3.3 (good), v3.4 (good) e) stable regression patch v3.3 (good), v3.3.1 (+) (bad), v3.4 (+) (bad) e.1) stable regression patch, normal fix v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.4 (good) e.2) stable regression patch, lost fix v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.4 (+) (bad) As you can see, even in the worst-case scenarios, there's no difference between (c) and (e.2). But what you are saying is that it doesn't matter at which point the issue with the patch is found, (e.2) has to be avoided *at all costs*, but you don't explain _why_. What is so different between (c) and (e.2)? And this is the worst-case scenario, I keep hearing people that this has happened in the past, but I don' think so, I think what has happened is: f) stable patch fix, lost v3.3 (bad), v3.3.1 (+) (good), v3.4 (bad) That I can see happening, and the current rules ensure that would not happen, but (e.2)? I yet have to see any evidence of this happening in the past. But lets be realistic; most likely the issue would be and fixed in upstream (d), so it doesn't matter what happens in stable, the end result would be the same (e.1). In fact in this particular patch people found problems in v3.4-rc1, so all evidence points out that we would have ended up in (e.1), not (e.2). So, if we expand the possibilities in the current situation, we have: 0) v3.3 (good), v3.3.1 (good), v3.3.2 (good), v3.3.3 (good), v3.4 (+) (bad), v3.4.1 (good) 1) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.3.3 (good), v3.4 (good), v3.4.1 (good) 2) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (+) (bad), v3.3.3 (good), v3.4 (good), v3.4.1 (good) 3) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.3.3 (good), v3.4 (+) (bad), v3.4.1 (good) #unlikely 4) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (+) (bad), v3.3.3 (+) (bad), v3.4 (+) (bad), v3.4.1 (good) #unlikely It looks like the patch is going both to upstream and stable (1), which is ideal, but when faced with the option between (2) and (3), you say (3) must absolutely be avoided even though it's basically the same as (0), which is the norm for thousands of patches that don't get back-ported to stable (and it's also unlikely to happen). Why? Plus, (1) (2) (3) (4) are already bad situations, and should be avoided at all costs; patches to stable are not supposed to be potentially dangerous, they are not meant be breaking things. > Another point is that you don't want stable to merge, revert, merge again, > revert again etc... This happened a little bit during 2.6.32 because some > fixes were not really obvious. It's common for some fixes to have to be > adapted for stable branches, and to have side effects, hence the review > cycle. We need to limit these random issues as much as possible if we > don't want users to lose trust in the stable branches. This is extremely > important. So picking random fixes that have not been qualified by all > interested parties in stable is inappropriate. Reverting without evaluating > impacts is one form of picking a random fix. Yeah, but that is not the case here, the options are clear; (a) go back to a previous state where power management doesn't work correctly, (b) stay in the current state where the system goes to a completely unusable state. > What you should have done would have been to reply to Greg saying "wait a > minute, we still have an issue with patch XX, I'm trying to get it reverted > in upstream and will send you the commit ID, it would be nice to have it in > 3.3.2". It wastes less time for everyone and achieves the same result. There's a lot of people affected by this issue, and a lot of noise. Personally I didn't receive the revert patch, so I could not comment on it. I think this patch should have been sent to LKML, but one cannot expect everyone to do the perfect thing all the time. > Once again, if you think that the stable branch you're using is not stable > enough for you, pick another one. Greg maintains multiple branches so that > everyone is satisfied. The risk of bugs over time probably looks like > (cos(t)+1)/t. Find an older branch with a much smaller risk of regressions > and be done with it. I'm not sure I would want to use 'stable' anymore, because clearly, the main goal doesn't seem to be *stability* as I thought. Apparently it's supposed to be a testing ground for patches queued for the next release. > Last point, you should note that you're the only one here who doesn't > understand the process. That doesn't make you a fool, but it should tell you > that you probably need to think a bit further before telling people how they > should work, especially when all other ones agree on the benefits of the > process, including Arnd explaining that FreeBSD had been facing the exact > same trouble and now applies the same process. It is not just a small band > of nerds doing this for fun right here, but seems to be more generalized. Ad populum. The fact that I'm questioning the process doesn't mean I don't understand it. But if you are not open to criticism, fine. Cheers. -- Felipe Contreras
next prev parent reply other threads:[~2012-04-13 10:04 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 2012-04-15 17:15 ` [ath9k-devel] " 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 [this message] 2012-04-13 10:04 ` 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=CAMP44s36PFbo6R1Wa5ZULByOS2qQFad-e6Mavgjv9B3v-oGFoA@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=davem@davemloft.net \ --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=stable@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=w@1wt.eu \ /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.