linux-kernel - Re: [GIT PULL] Ceph updates for 4.6-rc1

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]

Message-ID: <CA+55aFyXACVwL6inthTv=Orvp_6wDaA1c_BLvwJTYBORQTXa+w@mail.gmail.com>
Date:	Sat, 26 Mar 2016 11:30:12 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Sage Weil <sage@...hat.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ceph-devel <ceph-devel@...r.kernel.org>
Subject: Re: [GIT PULL] Ceph updates for 4.6-rc1

On Fri, Mar 25, 2016 at 6:39 PM, Sage Weil <sage@...hat.com> wrote:
>
> This series is based on a recent merge of Al's tree to avoid conflicts
> with his splice_dentry changes.

Once again, and with feeling: please PLEASE stop doing these idiotic things.

You should worry about *your* code. Don't worry about my merge. Don't
worry about other trees. Make sure YOUR code is well-tested and
stable, and make sure there is absolutely nothing questionable there.

This whole idiotic "let's rebase on top of something else because of a
tiny conflict" is a disease.

I'm simply not pulling this. If you insist on sending me branches that
have been rebased in the last day, then I will insist on just waiting
for the next merge window.

It really is that simple.

This pull request came in very late in the merge window, and the code
clearly has had almost zero actual testing since it was recently
rebased.

The fact that it avoids a merge conflict is not worth it.

Stop doing this idiotic crazy thing. How many times do I have to tell
people? When  you rebase, you are throwing your old testing away, and
you're also making me get new commits that are different from the
linux-next commits.

I'm not AT ALL interested in getting newly minted untested crap the
last day of the merge window.

Really.

                      Linus