Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932748AbbKMU16 (ORCPT ); Fri, 13 Nov 2015 15:27:58 -0500 Received: from mail-io0-f172.google.com ([209.85.223.172]:32887 "EHLO mail-io0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754704AbbKMU1x (ORCPT ); Fri, 13 Nov 2015 15:27:53 -0500 MIME-Version: 1.0 In-Reply-To: <1447444535.23126.119.camel@haakon3.risingtidesystems.com> References: <1447408790.23126.109.camel@haakon3.risingtidesystems.com> <1447444535.23126.119.camel@haakon3.risingtidesystems.com> Date: Fri, 13 Nov 2015 12:27:52 -0800 X-Google-Sender-Auth: PEJtfh0uPn_5TpQf79avNiccmfM Message-ID: Subject: Re: [GIT PULL] target updates for v4.4-rc1 From: Linus Torvalds To: "Nicholas A. Bellinger" Cc: target-devel , linux-scsi , LKML , Christoph Hellwig , Joel Becker , Linux-fsdevel , Andrzej Pietrasiewicz , Felipe Balbi Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4489 Lines: 96 On Fri, Nov 13, 2015 at 11:55 AM, Nicholas A. Bellinger wrote: > >> So just to make it really clear to people: if you ignore the reports >> from linux-next, then I will damn well ignore you. Comprende? Fair is >> fair. > > Would you accept an updated PULL request with Alexander's patch, or > prefer this whole series wait until v4.5..? You can't just apply Alexander's patch, because that patch wouldn't compile in your tree - it comes about as a conflict due to me having gotten commit 7bd1d4093c2f ("stm class: Introduce an abstraction for System Trace Module devices") from one of Greg's pulls. But what I want maintainers to do is to *tell* be about these things. I have absolutely no issues with handling merge conflicts - they happen all the time. But when those merge conflicts were known about from linux-next, and particularly when those merge conflicts were silent semantic conflicts that didn't even show up as an actual explicit conflict int he git history (only as a compile issue - or worse - a runtime problem), then I want maintainers to (a) show they were aware of it (you should have been, or there is something wrong in our process) and (b) let me know about it and point to the resolution. That way I'm not taken by surprise, and things won't fall through the cracks. Yes, I do allmodconfig builds between every pull, which is how I noticed this, but that doesn't always catch things either, and it doesn't catch _other_ configs that may be relevant too. Note that it also doesn't mean that I want you to do the merge for me. I want to be aware of these issues, and I want to see the resolution, and I'm more than happy to do it myself. In fact, I almost insist, unless the resolution is _so_ painful that I push it back to the maintainer. I just want the heads-up about the issue and about the fix for the issue, because that is the upside of linux-next: these things gets noticed there first, exactly so that people can be aware of them. And yes, I also react a lot more negatively when things like this happen with the very end of the merge window in sight. I usually make the actual rc1 release on Sunday, but I want Sunday itself to be pretty much quiet apart from perhaps a "oops, sorry, here's a fix that we just noticed" kind of issues. I don't want to be taken by surprise like this just a couple of days before I want to do the rc. So please try to just re-send the pull, but this time with explanations of the conflict and a pointer to the fixup for the conflict (some people end up doing a pre-merge for me as an example, in _addition_ to the unmerged tree they send me). I may or may not then use the particular conflict resolution that I'm pointed at or told about (because maybe I decide to do it my way), but regardless it really helps to have a heads-up. And when people go to the effort and do a "and here's a pre-merged version", I basically *always* then end up doing something like git checkout -b test-merge ORIG_HEAD git pull git diff master .. everything looks good .. git checkout master git branch -D test-merge just to check that yes, we agreed (or, even more interestingly, how our different merges differed). Now, *most* of the time there are no conflicts at all. And then occasionally there are trivial conflicts that just come about because people touched the MAINTAINERS file close to each other. Don't worry about those truly trivial ones, they certainly don't need any kind of "here's how to resolve them" or a pre-merged tree. You could *mention* them ("You'll get a trivial conflict with an obvious resolution in file XYZ"), but quite frankly, even that isn't required. So I'm not asking for some silly extra busy-work. But when linux-next notified you about a conflict, and it wasn't just something trivial, then *that* is when I just want to be told. And yes, part of that "I want to be told" is literally just because I want to see that the whole "process" worked, and that things had been in linux-next, and people had reacted to them. Usually actually resolving the conflict isn't all that hard, and I can always find the linux-next discussions (like I did now). See? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/