{"thread":{"id":"13504","subject":"Re: + wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree","startedAt":"2008-05-14T04:57:37Z","lastAt":"2008-05-14T17:50:42Z","messageCount":4,"participants":["Andrew Morton","David Miller","John W. Linville"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"76912","messageId":"20080513215737.fe1bdebd.akpm@linux-foundation.org","threadId":"13504","inReplyTo":"20080513.213927.191790810.davem@davemloft.net","subject":"Re: + wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-05-14T04:57:37Z","receivedAt":"2008-05-14T04:57:37Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Tue, 13 May 2008 21:39:27 -0700 (PDT) David Miller wrote:\n\n> From: akpm@linux-foundation.org\n> Date: Tue, 13 May 2008 21:05:50 -0700\n> \n> > Subject: wireless: fix \"iwlwifi: unify init driver flow\"\n> > From: Andrew Morton \n> > \n> > drivers/net/wireless/iwlwifi/iwl-core.c: In function 'iwlcore_init_geos':\n> > drivers/net/wireless/iwlwifi/iwl-core.c:323: error: implicit declaration of function 'iwlcore_init_ht_hw_capab'\n> > \n> > This (or something like it) should be folded into the base patch to avoid\n> > breaking bisection, please.\n> > \n> > Cc: Ron Rindjunsky \n> > Cc: Tomas Winkler \n> > Cc: John W. Linville \n> > Cc: Stephen Rothwell \n> > Signed-off-by: Andrew Morton \n> \n> Andrew, you have to figure out what we're supposed to do here.\n\nWell someone does ;)\n\n> If I \"fold in the patch\" to avoid breaking bisection, I have to\n> completely rebase my tree screwing up everyone of my downstream\n> developers.\n> \n> Or is this some patch I'm supposed to remember to fold in several\n> months from now, to some random changeset out of thousands, when the\n> merge window opens?\n> \n> Neither option is tenable, and the headaches of neither are\n> worth it purely for the sake of bisection.\n> \n> My solution to the bisection problem is to wait a day before pushing\n> out usually, it's a best effort thing. I do as many sanity builds as\n> I can, and we also hope that someone during that day might solve the\n> problem independantly and post a fix. That way I can fix it in my\n> tree locally before the tree goes public.\n> \n> And I think this is the most reasonable approach.\n> \n> Once I push something to my public tree, quite frankly, it's the real\n> deal, it's staying there, and it's a part of the permanent record.\n> And therefore, we'll put fixes on top.\n\nWhat goes into Linus's tree is there for ever and I do think that all\nthe short-term things we do should be built around making the permanent\nrecord as good as possible.\n\nThis is a(nother) case where a toolchain/process problem is forcing us\nto do something which we don't want to do. In an ideal world we should\ntell the git developers \"we want x, please\" and hopefully they can give\nit to us. Because right now, we're having to work around shortcomings\nin git and we are producing a lesser product as a result of this. A tool\nshould follow the way in which humans want to work, not vice versa.\n\nShort-term... dunno. Perhaps you could have a two-weekly\nbroadly-announced rebase in which you integrate all these dribs and\ndrags back into their proper place? Commit them with some well-known\nidentifier in the title so that they can all be located when that time\ncomes?\n\nIf you announce such a rebase a day or so beforehand then all the guys\nwho feed into you could get their stuff merged up into your tree to\nminimise their pain when the rebase happens, perhaps.\n\n(That being said, this particular no-compile isn't a huge problem - it\ncan be worked around with a Kconfig change. But that isn't generally\nthe case)\n"},{"id":"76913","messageId":"20080513.221529.20855966.davem@davemloft.net","threadId":"13504","inReplyTo":"20080513215737.fe1bdebd.akpm@linux-foundation.org","subject":"Re: + wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree","fromName":"David Miller","fromEmail":"davem@davemloft.net","sentAt":"2008-05-14T05:15:29Z","receivedAt":"2008-05-14T05:15:29Z","isPatch":false,"sender":{"key":"davem@davemloft.net","avatar":null},"body":"From: Andrew Morton \nDate: Tue, 13 May 2008 21:57:37 -0700\n\n> This is a(nother) case where a toolchain/process problem is forcing us\n> to do something which we don't want to do. In an ideal world we should\n> tell the git developers \"we want x, please\" and hopefully they can give\n> it to us. Because right now, we're having to work around shortcomings\n> in git and we are producing a lesser product as a result of this. A tool\n> should follow the way in which humans want to work, not vice versa.\n\nThis has beaten like a dead horse a thousand times. Bringing\nit up again isn't likely to cause further progress. :)\n\n> Short-term... dunno. Perhaps you could have a two-weekly\n> broadly-announced rebase in which you integrate all these dribs and\n> drags back into their proper place? Commit them with some well-known\n> identifier in the title so that they can all be located when that time\n> comes?\n> \n> If you announce such a rebase a day or so beforehand then all the guys\n> who feed into you could get their stuff merged up into your tree to\n> minimise their pain when the rebase happens, perhaps.\n\nThis, along with the idea of taking care of all of the \"dribs\" right\nbefore the real merge, is error prone.\n\nIt means I have to play with large collections of patches all at one\ntime. The reason I use GIT is because I'm stupid and make mistakes,\ntherefore I don't like playing with patches.\n\nI used to play this game, it's a lot of work and it sucks. One\n\"drib\" can require fixing up 200 patches down the chain. And\nI've had this happen to me all the time in the past when I was\nrebasing all the time.\n\nNot this specific case, mind you, but it is a real concern in general.\n"},{"id":"76940","messageId":"20080514123432.GB3349@tuxdriver.com","threadId":"13504","inReplyTo":"20080513.221529.20855966.davem@davemloft.net","subject":"Re: + wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree","fromName":"John W. Linville","fromEmail":"linville@tuxdriver.com","sentAt":"2008-05-14T12:34:32Z","receivedAt":"2008-05-14T12:34:32Z","isPatch":false,"sender":{"key":"linville@tuxdriver.com","avatar":"https://gravatar.com/avatar/6d8306e6a14a7040d9197d96418fe97d4e6a76024ad7585f915c1170701aca01?d=mp&s=160"},"body":"On Tue, May 13, 2008 at 10:15:29PM -0700, David Miller wrote:\n\n> I used to play this game, it's a lot of work and it sucks. One\n> \"drib\" can require fixing up 200 patches down the chain. And\n> I've had this happen to me all the time in the past when I was\n> rebasing all the time.\n\nI have to agree with Dave.\n\nMoreover, I used to get regular complaints about the old \"regular\nrebase\" process. We switched to a \"pull and merge\" process for 2.6.25,\nand in that period nearly all of the process-related complaints\ndisappeared for me.\n\nTo some degree this is a \"pick your poison\" issue, and for most people\nrebasing seems like the deadlier poison.\n\nJohn\n-- \nJohn W. Linville\nlinville@tuxdriver.com\n"},{"id":"76963","messageId":"20080514105042.12a112e4.akpm@linux-foundation.org","threadId":"13504","inReplyTo":"20080514123432.GB3349@tuxdriver.com","subject":"Re: + wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-05-14T17:50:42Z","receivedAt":"2008-05-14T17:50:42Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Wed, 14 May 2008 08:34:32 -0400 \"John W. Linville\" wrote:\n\n> On Tue, May 13, 2008 at 10:15:29PM -0700, David Miller wrote:\n> \n> > I used to play this game, it's a lot of work and it sucks. One\n> > \"drib\" can require fixing up 200 patches down the chain. And\n> > I've had this happen to me all the time in the past when I was\n> > rebasing all the time.\n> \n> I have to agree with Dave.\n> \n> Moreover, I used to get regular complaints about the old \"regular\n> rebase\" process. We switched to a \"pull and merge\" process for 2.6.25,\n> and in that period nearly all of the process-related complaints\n> disappeared for me.\n> \n\nWell. Have you ever been an hour and a half into a bisection at 3AM\nthen hit a massive oops deep in the TCP code which was spread across a\nlarge number of commits? I have and it wasn't fun. iirc I gave up and\nwent to bed.\n\n> To some degree this is a \"pick your poison\" issue, and for most people\n> rebasing seems like the deadlier poison.\n\nWell yes. We'd like the best of both worlds, only we cannot have it. \nAnd the sole _reason_ we cannot have it is due to restrictions in git\n.\n"}]}