All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-edac <linux-edac@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [GIT PULL] EDAC updates for 4.
Date: Wed, 24 Jun 2015 15:15:03 +0200	[thread overview]
Message-ID: <20150624131502.GE32642@pd.tnic> (raw)
In-Reply-To: <CA+55aFw8Jd9NdMY=n9BcnPtj=pJu1D+0J43ER9mRrCt-1cAPhw@mail.gmail.com>

On Wed, Jun 24, 2015 at 06:01:41AM -0700, Linus Torvalds wrote:
> On Wed, Jun 24, 2015 at 5:40 AM, Linus Torvalds
> <torvalds@linux-foundation.org> 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.
--

  reply	other threads:[~2015-06-24 13:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-24 12:14 [GIT PULL] EDAC updates for 4 Linus Torvalds
2015-06-24 12:30 ` Borislav Petkov
2015-06-24 12:40   ` Linus Torvalds
2015-06-24 13:01     ` Linus Torvalds
2015-06-24 13:15       ` Borislav Petkov [this message]
2015-06-24 17:13         ` [GIT PULL] EDAC updates for 4.2 - v2 Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150624131502.GE32642@pd.tnic \
    --to=bp@suse.de \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.