block/IO bits for 2.6.36-rc1
in [Kernel]
|
Prev: Resend: [PATCH] blkdev: fix blkdev_issue_zeroout return value
Next: regulator: Fix WM8994 LDO enable gpio set when probed
From: Jens Axboe on 6 Aug 2010 06:50 On 2010-08-06 12:38, Jens Axboe wrote: > Hi Linus, > > This is the big round of updates for the IO bits for 2.6.36-rc1. > Not sure what happened on the excessive number of merges listed > as: > > Merge branch 'for-2.6.36' into for-next > > as these should 1) just have been regular fast forwards, and 2) > not be listed under 2.6.36 when the pull was in the other > direction. I tend to run -git git versions, so perhaps there > was a bad version in there. I was planning on reshuffling > the branch, but it's 3 months of churn and fixups in there and > that would take me a while. Let me know if you absolutely > hate it and I'll do it. Oh, and the 'master' merges into for-2.6.36 were all done to resolve conflicts. I had to do two just this week after you starting pulling in changes from others, as they were beyond git to automatically resolve. So there are no excessive merges, just the weird listings for for-2.6.36 -> for-next. -- Jens Axboe Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 6 Aug 2010 12:00 On Fri, Aug 6, 2010 at 8:44 AM, Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > > ... And > once you _do_ ask me to merge from you, I still don't want you to do > the merge, because I want to know about what conflicts. That's where > the bugs almost always are. Actually, let me rephrase that. Almost all bugs are just individual commits. But the "oh, we had conflicts between trees" is where the subtle bugs that are due to interactions between two different development projects tend to be.. So "almost always" is not really true - almost always bugs are just simply bugs: incorrect code. I wish we didn't have that, but hey, reality clearly hates me. But the reason I want to see the merge problems (even if I then occasionally end up having to send it back and say "ok, I see the merge problem and I can't handle it, you do it for me") is because that way I _see_ when people step on each others feet. Because when it happens, it's ripe for nasty issues, including simply ones that are due to bad development habits, or due to bad source tree organization. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jens Axboe on 7 Aug 2010 03:40 On 08/06/2010 05:51 PM, Linus Torvalds wrote: > On Fri, Aug 6, 2010 at 8:44 AM, Linus Torvalds > <torvalds(a)linux-foundation.org> wrote: >> >> ... And >> once you _do_ ask me to merge from you, I still don't want you to do >> the merge, because I want to know about what conflicts. That's where >> the bugs almost always are. > > Actually, let me rephrase that. > > Almost all bugs are just individual commits. But the "oh, we had > conflicts between trees" is where the subtle bugs that are due to > interactions between two different development projects tend to be.. > > So "almost always" is not really true - almost always bugs are just > simply bugs: incorrect code. I wish we didn't have that, but hey, > reality clearly hates me. But the reason I want to see the merge > problems (even if I then occasionally end up having to send it back > and say "ok, I see the merge problem and I can't handle it, you do it > for me") is because that way I _see_ when people step on each others > feet. Because when it happens, it's ripe for nasty issues, including > simply ones that are due to bad development habits, or due to bad > source tree organization. OK, so a question on this. Say a bug surfaces in the middle of the release and we push in a change to fix that at 2.6.36-rc3 time. This same patch will not apply directly to the branch holding 2.6.37 patches due to code reshuffling or whatnot. How do you want that handled? I can't pull in your branch and resolve it. The merge conflict may not be visible to you until 2.6.36 is released and I want to offload the patches to you, but it will be visible in linux-next pretty much immediately. This puts a lot of extra work on Stephen. -- Jens Axboe Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 7 Aug 2010 17:10 On Sat, Aug 7, 2010 at 12:31 AM, Jens Axboe <jaxboe(a)fusionio.com> wrote: > > Sometimes urgent patches will sit in for-linus and then I will merge > those in to for-2.6.36 to save Stephen the hassle of carrying conflict > update patches. The merges I saw weren't even urgent, because you had never actually pushed them to me as such for the previous release. So both sides of the merge was "for-2.3.36" as far as I can tell. That's what makes me think there's some odd duplication of branches with no point (except to make the history look ugly). Now, don't get me wrong - I _like_ branches. I love it when people maintain different branches for different features, and then merge them together in order for me to pull them (or just ask me to pull multiple branches). See for example merge commit 415cb47998 that Pekka did to create one single thing for me to pull when he had maintained four different topic branches. Or see the x86 "tip" pulls from Ingo, Thomas and Peter as an example of just asking me to pull multiple branches separately. So branches (and the merges that go with them) are a wonderful thing when they _clarify_ history. I don't mind merges at all in that case. When the merge has a reason for existing, it's actually a good thing, and one guiding model for that is to ask yourself "Does this merge message make sense and tell people something interesting"? So just to take a look at that merge by Pekka: commit 415cb47998c5 Merge: 9fe6206f4006 78b435368fcd d602dabaeba7 2bce64858442 bc6488e91078 Author: Pekka Enberg <penberg(a)cs.helsinki.fi> Date: Wed Aug 4 22:04:43 2010 +0300 Merge branches 'slab/fixes', 'slob/fixes', 'slub/cleanups' and 'slub/fixes' into for-linus and even outside of the history itself, I'd argue that the merge message already tells you _why_ the merge was done. Despite it being just the trivial automatic merge message that git generates on its own. The merge actually clarifies history, I think. So one guiding light for doing merges is really just to ask yourself whether the merge message will actually tell anybody anything. And in particular, merge messages like Merge branch 'master' into for-2.6.36 don't do that. Think about it as an outsider: what does the above tell anybody? It looks like it has no relevant information in it. That's a hint that the merge simply shouldn't have been done. It's just a _hint_ though. I'm not saying that the merge message always has to be a revelation. I'm just saying that a merge message like "Merge branch 'master' ..." should raise red flags. Now, the "into for-2.6.36" part is still informative. But if there are multiple merges of the same branch into that same thing, then that is another red flag, bringing up the question "why did he merge something that wasn't ready yet". What I'm trying to say is that if you start thinking about what the merge messages tell outsiders, then you probably are thinking about merges the right way. And if the automatic git messages don't seem to tell the reason, one thing you can actually do is to do git pull --no-commit .... git commit and edit the merge message manually to explain what/why the merge does (or you could do "git commit --amend" after the pull, but I would encourage people to do the commit separately if only because it actually shows that you thought about the issue _before_ you did the pull rather than as a "oops, that merge message was uninformative, let me fix it up" after-the-fact) > I tend to merge in your tree when I _know_ there's a conflict there, > since it's much easier to fix things up when they happen and the change > is fresh, than wait potentially 2-3 months and then have to resolve > everything in one go. Now, this is a good reason for a merge. But: - make that reason known and - DON'T DO THIS WHILE THE CODE IS STILL UNDER DEVELOPMENT I'm shouting, because the second thing is what really gets me: daily merges. If you are doing daily merges for conflict resolution, that's a big big red flag. That means that you're merging stuff while it's still being developed. So the "let's do a merge to avoid hard merges much later" is a good reason to merge, but in that case do point it out, and do it after the development has died down, and after you know that you aren't going to have another thing that will also clash. In other words, wait a few days. Or even a week or two. Don't think "Oh, I just applied something that I know will clash, so let's merge it now". Let the code calm down, and make sure it's all done. And never _ever_ merge a random point. If the merge window is months away, you'll know that there is going to be a few -rc releases still, so there's ample time to just wait a week or so, and then do a merge like # I know this is going to have conflicts, so I'm not even doing --no-commit git merge v2.6.35-rc5 # edit the message to say _why_ you're merging an -rc release, talking about resolving the conflicts early see? If you do this, your history will suddenly make sense. There won't be the daily merges, and the merges that _are_ there are actually explanatory. A bad merge has turned into a good merge, and history doesn't look ugly. So again, I'm not saying that merges are bad. I'm saying that random and unexplained merges are bad. > But if you don't like that way of doing things, I will stop and just > keep for-2.6.X+1 patches in a branch that is based off 2.6.X and never > updated. I will try that for the next release and see how that goes. It's worth trying. In fact, it might be worth trying having a few different branches, especially since there has been several clearly different development threads for the block layer. It would be _beautiful_ if you were to send me a couple of different pull requests for things like "fix writeback" and "update cfs", and they'd be independent. Because I think they really _are_ independent things. But see above. Merges per se are not evil or bad. But thoughtless merges are bad (and quite frankly, I don't mind a _couple_ of unnecessary merges. It's when I see the daily kind that I go "no, there's something seriously wrong here". So none of this is about hard rules that have to be followed 100%, it's more flexible than that). Give it a try, Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 7 Aug 2010 17:20
On Sat, Aug 7, 2010 at 12:34 AM, Jens Axboe <jaxboe(a)fusionio.com> wrote: > > OK, so a question on this. Say a bug surfaces in the middle of the > release and we push in a change to fix that at 2.6.36-rc3 time. This > same patch will not apply directly to the branch holding 2.6.37 patches > due to code reshuffling or whatnot. How do you want that handled? I > can't pull in your branch and resolve it. The merge conflict may not be > visible to you until 2.6.36 is released and I want to offload the > patches to you, but it will be visible in linux-next pretty much > immediately. So I think there's a few possible answers to that. One is the one I outlined in my previous email: merge the next -rc tag, and explain why you merged it in the commit message. That not only makes the merge commit message be way more informative ("Merge commit v2.6.3x-rcy" rather than "Merge branch 'master'"), but it also automatically acts as a "rate limiter" for the merges. Now, that may cause problems for linux-next for a few days too, since I think linux-next always starts from some random tree-of-the-day of mine. That itself may be more indicative of a linux-next problem, though. It might well make sense to base linux-next itself on the latest tagged release rather than on some random daily thing (and if the things that get merged _into_ linux-next then are based on a random daily thing and bring linux-next forward, then that's a problem with the trees getting merged - they shouldn't be doing that either). The other possibility is for you to do throw-away merges just for linux-next. That way _you_ do the merge (not Stephen or one of the linux-next helpers), but the merge is going only into for-next, not into your for-2.6.36 branch. "git rerere" will help you re-do the same merge for future for-next trees - the same way linux-next already generally only needs to do the merge resolution once. Then, when you actually want to send it to me, at that point (if it's a really complicated merge and you know it's too complex for me), you can do one final merge into 'for-linus' before you send me the pull request. Again, git rerere will help you re-use your previous merge resolutions. Or don't merge at all when you send it to me, and only do the merge if I then reply with "ok, that's too complicated for me". I will _never_ complain about you sending me something I can't merge. I may throw it back at you, but I won't complain about you trying to give me merge work. I really do like knowing about the conflicts. Of course, if I do the merge conflict resolution I may then see something odd and complain about it. Something I might not have even noticed if it hadn't been pointed out to me by the conflict ;) Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |