| Message ID | 20130205095844.GZ1906@pengutronix.de |
|---|---|
| State | New |
| Headers | show |
On Tue, Feb 05, 2013 at 10:58:44AM +0100, Sascha Hauer wrote: > Hi Arnd, Olof, > > Please pull these two fixes for v3.8 If you haven't heard, Linus wants each and every patch going into v3.8 meeting this criteria: fix major security issues, big user-reported regressions, or nasty oopses. and individually justified: So think twice - or thrice - before sending me patches or a pull request for -rc7. You need to have some seriously good reasons for doing so, and you need to state those reasons very clearly. And I don't just mean for the pull request in general, I mean for every single patch in it. ... In other words, "It fixes a bug" just isn't good enough. The bug needs to be something that actually matters.
On Tue, Feb 05, 2013 at 11:08:04AM +0000, Russell King - ARM Linux wrote: > On Tue, Feb 05, 2013 at 10:58:44AM +0100, Sascha Hauer wrote: > > Hi Arnd, Olof, > > > > Please pull these two fixes for v3.8 > > If you haven't heard, Linus wants each and every patch going into v3.8 > meeting this criteria: > > fix major security issues, big user-reported regressions, or nasty > oopses. > > and individually justified: > > So think twice - or thrice - before sending me patches or a pull > request for -rc7. You need to have some seriously good reasons for > doing so, and you need to state those reasons very clearly. And I > don't just mean for the pull request in general, I mean for every > single patch in it. > ... > In other words, "It fixes a bug" just isn't good enough. The bug needs > to be something that actually matters. At least 'ARM: i.MX25: clk: parent per5_clk to AHB clock' is a regression that causes nasty oopses. Admittedly, it wasn't introduced in the last merge window and the board requiring the fix needs out of tree patches. I'm fine with these going into v3.9 and waiting for the first stable patch to get the fix for the above. Sascha
On Tuesday 05 February 2013, Sascha Hauer wrote: > > So think twice - or thrice - before sending me patches or a pull > > request for -rc7. You need to have some seriously good reasons for > > doing so, and you need to state those reasons very clearly. And I > > don't just mean for the pull request in general, I mean for every > > single patch in it. > > ... > > In other words, "It fixes a bug" just isn't good enough. The bug needs > > to be something that actually matters. > > At least 'ARM: i.MX25: clk: parent per5_clk to AHB clock' is a > regression that causes nasty oopses. Admittedly, it wasn't introduced in > the last merge window and the board requiring the fix needs out of tree > patches. > > I'm fine with these going into v3.9 and waiting for the first stable > patch to get the fix for the above. My rules is usually: if it's important enough to have it backported into a stable kernel, then it's also important enough to get sent at any time during the bug fix phase. The patch you mentioned certainly fits that category. The other one might as well, but the patch description does not actually say what the impact of the bug is, so it is hard to tell. Arnd
On Tue, Feb 05, 2013 at 01:12:11PM +0000, Arnd Bergmann wrote: > On Tuesday 05 February 2013, Sascha Hauer wrote: > > > So think twice - or thrice - before sending me patches or a pull > > > request for -rc7. You need to have some seriously good reasons for > > > doing so, and you need to state those reasons very clearly. And I > > > don't just mean for the pull request in general, I mean for every > > > single patch in it. > > > ... > > > In other words, "It fixes a bug" just isn't good enough. The bug needs > > > to be something that actually matters. > > > > At least 'ARM: i.MX25: clk: parent per5_clk to AHB clock' is a > > regression that causes nasty oopses. Admittedly, it wasn't introduced in > > the last merge window and the board requiring the fix needs out of tree > > patches. > > > > I'm fine with these going into v3.9 and waiting for the first stable > > patch to get the fix for the above. > > My rules is usually: if it's important enough to have it backported > into a stable kernel, then it's also important enough to get sent > at any time during the bug fix phase. > > The patch you mentioned certainly fits that category. The other one > might as well, but the patch description does not actually say what > the impact of the bug is, so it is hard to tell. Look at what Linus is saying. Too much stuff went into -rc6. He doesn't want that happening for -rc7. He wants -rc7 to be really tiny, like almost _no_ changes. Look at the description about what he wants to see: he doesn't want to see user visible regressions. He wants to see _big_ user visible regressions only. Also look at what he's saying wrt describing _every_ _single_ _patch_ in your pull request with a justification why it's there. Can you do this for every patch you have planned to push? Do you have sufficient information from those sending you these pull requests for fixes to v3.8 to do that? If not, you probably shouldn't be pulling them with a view to sending them to Linus (unless you wish to be flamed.) I certainly can't with the three patches I had queued for fixes before -rc6. They may be fixing problems which cause a few platforms not to boot or oops at boot, but I can't justify them against what Linus has said. So I'm going to wait for the next merge window and put them in with a stable CC. There's more patches like that post-rc6: there's one which fixes an obscure problem with 'make' which occurs with 2G:2G VM split. But I'm not pushing that one either because it's not a _big_ enough problem (it's only had _one_ user report it.) One user is not sufficient justification.
On Tue, Feb 05, 2013 at 01:27:59PM +0000, Russell King - ARM Linux wrote: > On Tue, Feb 05, 2013 at 01:12:11PM +0000, Arnd Bergmann wrote: > > On Tuesday 05 February 2013, Sascha Hauer wrote: > > > > So think twice - or thrice - before sending me patches or a pull > > > > request for -rc7. You need to have some seriously good reasons for > > > > doing so, and you need to state those reasons very clearly. And I > > > > don't just mean for the pull request in general, I mean for every > > > > single patch in it. > > > > ... > > > > In other words, "It fixes a bug" just isn't good enough. The bug needs > > > > to be something that actually matters. > > > > > > At least 'ARM: i.MX25: clk: parent per5_clk to AHB clock' is a > > > regression that causes nasty oopses. Admittedly, it wasn't introduced in > > > the last merge window and the board requiring the fix needs out of tree > > > patches. > > > > > > I'm fine with these going into v3.9 and waiting for the first stable > > > patch to get the fix for the above. > > > > My rules is usually: if it's important enough to have it backported > > into a stable kernel, then it's also important enough to get sent > > at any time during the bug fix phase. > > > > The patch you mentioned certainly fits that category. The other one > > might as well, but the patch description does not actually say what > > the impact of the bug is, so it is hard to tell. > > Look at what Linus is saying. Too much stuff went into -rc6. He doesn't > want that happening for -rc7. He wants -rc7 to be really tiny, like > almost _no_ changes. Look at the description about what he wants to > see: he doesn't want to see user visible regressions. He wants to see > _big_ user visible regressions only. > > Also look at what he's saying wrt describing _every_ _single_ _patch_ in > your pull request with a justification why it's there. Can you do this > for every patch you have planned to push? Do you have sufficient > information from those sending you these pull requests for fixes to v3.8 > to do that? If not, you probably shouldn't be pulling them with a view > to sending them to Linus (unless you wish to be flamed.) > > I certainly can't with the three patches I had queued for fixes before > -rc6. They may be fixing problems which cause a few platforms not to > boot or oops at boot, but I can't justify them against what Linus has > said. So I'm going to wait for the next merge window and put them in > with a stable CC. There's more patches like that post-rc6: there's one > which fixes an obscure problem with 'make' which occurs with 2G:2G VM > split. But I'm not pushing that one either because it's not a _big_ > enough problem (it's only had _one_ user report it.) One user is not > sufficient justification. Yeah, I was just looking at my queue here (and then came upon this thread). >From what we have queued up right now in arm-soc fixes, I don't see anything that _truly_ needs to go in for 3.8. If someone feels differently, let me know (with a very solid motivation) and I will consider sending it up. But right now I am likely going to fold the 'fixes' branch into 'fixes-non-critical' for 3.9 instead. -Olof
On Tuesday 05 February 2013 10:44:19 Olof Johansson wrote: > > Yeah, I was just looking at my queue here (and then came upon this thread). > From what we have queued up right now in arm-soc fixes, I don't see anything > that _truly_ needs to go in for 3.8. > > If someone feels differently, let me know (with a very solid motivation) and > I will consider sending it up. But right now I am likely going to fold the > 'fixes' branch into 'fixes-non-critical' for 3.9 instead. I was going to put the Samsung fixes for the new bintutils in, but I suppose that can wait until 3.9, given that it has always been broken. Probably -stable material though. Arnd
On Tue, Feb 5, 2013 at 5:27 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > There's more patches like that post-rc6: there's one > which fixes an obscure problem with 'make' which occurs with 2G:2G VM > split. But I'm not pushing that one either because it's not a _big_ > enough problem (it's only had _one_ user report it.) One user is not > sufficient justification. Can you please make sure that one is marked for stable though? We're running Chrome OS in 2:2 on ARM, and we're likely going to move to 3.8 at some point. -Olof
Arnd, Olof, What's the status of this? I assume you haven't pulled it for -rc since it's not important enough, but could you pull it for -next then? Thanks Sascha On Tue, Feb 05, 2013 at 10:58:44AM +0100, Sascha Hauer wrote: > Hi Arnd, Olof, > > Please pull these two fixes for v3.8 > > Sascha > > The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7: > > Linux 3.8-rc6 (2013-02-01 12:08:14 +1100) > > are available in the git repository at: > > git://git.pengutronix.de/git/imx/linux-2.6.git tags/arm-imx-clk-fixes > > for you to fetch changes up to 4b526ca5f627188425184a22ed46c91baa602d43: > > ARM: i.MX25: clk: parent per5_clk to AHB clock (2013-02-05 10:54:35 +0100) > > ---------------------------------------------------------------- > ARM: i.MX: clock fixes > > - fix wrong timer clock on i.MX25 leading to strange timing inconsistencies > - fix SPI clocks for i.MX27 > > ---------------------------------------------------------------- > Gwenhael Goavec-Merou (1): > ARM: imx27: clk-imx27: SPI: Rename IPG clock and add PER clock > > Steffen Trumtrar (1): > ARM: i.MX25: clk: parent per5_clk to AHB clock > > arch/arm/mach-imx/clk-imx25.c | 3 +++ > arch/arm/mach-imx/clk-imx27.c | 9 ++++++--- > 2 files changed, 9 insertions(+), 3 deletions(-) > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
On Tuesday 12 February 2013, Sascha Hauer wrote: > Arnd, Olof, > > What's the status of this? I assume you haven't pulled it for -rc since > it's not important enough, but could you pull it for -next then? > Sorry for the delay, I've pulled it into the next/fixes-non-critical branch now. Arnd
Hi Arnd, Olof, Please pull these two fixes for v3.8 Sascha The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7: Linux 3.8-rc6 (2013-02-01 12:08:14 +1100) are available in the git repository at: git://git.pengutronix.de/git/imx/linux-2.6.git tags/arm-imx-clk-fixes for you to fetch changes up to 4b526ca5f627188425184a22ed46c91baa602d43: ARM: i.MX25: clk: parent per5_clk to AHB clock (2013-02-05 10:54:35 +0100) ---------------------------------------------------------------- ARM: i.MX: clock fixes - fix wrong timer clock on i.MX25 leading to strange timing inconsistencies - fix SPI clocks for i.MX27 ---------------------------------------------------------------- Gwenhael Goavec-Merou (1): ARM: imx27: clk-imx27: SPI: Rename IPG clock and add PER clock Steffen Trumtrar (1): ARM: i.MX25: clk: parent per5_clk to AHB clock arch/arm/mach-imx/clk-imx25.c | 3 +++ arch/arm/mach-imx/clk-imx27.c | 9 ++++++--- 2 files changed, 9 insertions(+), 3 deletions(-)