From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752744AbbFXNPV (ORCPT ); Wed, 24 Jun 2015 09:15:21 -0400 Received: from cantor2.suse.de ([195.135.220.15]:36726 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751973AbbFXNPQ (ORCPT ); Wed, 24 Jun 2015 09:15:16 -0400 Date: Wed, 24 Jun 2015 15:15:03 +0200 From: Borislav Petkov To: Linus Torvalds Cc: Linux Kernel Mailing List , linux-edac , the arch/x86 maintainers Subject: Re: [GIT PULL] EDAC updates for 4. Message-ID: <20150624131502.GE32642@pd.tnic> References: <20150624123047.GD32642@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 24, 2015 at 06:01:41AM -0700, Linus Torvalds wrote: > On Wed, Jun 24, 2015 at 5:40 AM, Linus Torvalds > wrote: > > > > You didn't actually test what you sent me. YOU TESTED SOMETHING > > ENTIRELY DIFFERENT. > > Btw, it worries me that not only are you in denial about this, > apparently you have always done it: > > "But I have always merged the tip/x86/ras branch which contained the x86 > changes into the EDAC tree when testing. Basically what I should've done > with the pull request too" "always" meant during the 4.1-rc cycle, of course. Only for this release. > because this shows that your workflow is just fundamentally broken. > > You should test *YOUR* branch. That's the primary thing. Make sure > your code works and makes sense, and nothing else really matters. > > Sure, feel free to go ahead and also test whatever other combinations > (more testing is never wrong), but those are very definitely > secondary, and aren't nearly as important. And it is never a > _replacement_ for testing your branch, it is always a "in addition > to". Ok, understood. > I'd much rather you test the thing you send me twice as much, and > *never* test any combination, than seeing that you primarily test > combinations with other branches. > > And yes, if it then turns out that there are often interactions with > other branches that means that the integrated thing doesn't work (even > after the individual branches have been tested extensively and work on > their own), then sure, that can be a problem. > > Those kinds of problems are fairly unusual, but they tend to mean that > multiple people are stepping on each others toes. It isn't all that > different from "those two development trees often cause conflicts", > and usually means that either the code needs some re-organization so > that people can work better independently, or it means that the > different branches really are working on the same thing, and perhaps > need to be working more closely together. > > But generally, the *less* intertwined you are, the better off you are. > It's usually much better to try to have different branches and > developers be as independent as possible, so that they don't get > serialization issues. Yeah, so as I said earlier, in hindsight, I should've stuck the error injection stuff completely into tip as it depends on it. But we carry it in drivers/edac/ for some archaic reason or because it was easier this way at the time. In the meantime, it depends so much on x86 facilities that it actually belongs into arch/x86/ras/. I even had patches which did that. I'll try to dust them off for 4.2-rc maybe, let's see what happens. In the meantime, I've zapped those two offending patches and am testing a v2 pull request. Thanks for explaining the situation, fully agreed and noted for the future. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --