linux-kernel - Re: [GIT PULL] EDAC updates for 4.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Jun 2015 06:01:41 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Borislav Petkov <bp@...e.de>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-edac <linux-edac@...r.kernel.org>,
	"the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [GIT PULL] EDAC updates for 4.

On Wed, Jun 24, 2015 at 5:40 AM, Linus Torvalds
<torvalds@...ux-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"

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".

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.

                        Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/