linux-kernel - Re: [GIT PULL] xen: fixes for 4.16 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]

Date:   Fri, 9 Feb 2018 10:48:40 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Juergen Gross <jgross@...e.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        xen-devel <xen-devel@...ts.xenproject.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [GIT PULL] xen: fixes for 4.16 rc1

On Fri, Feb 9, 2018 at 6:28 AM, Juergen Gross <jgross@...e.com> wrote:
>
>  git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.16-rc1-tag

So I've pulled this, but the back-merges *really* annoy me.

Seriously, DON'T DO MERGES IF YOU CANNOT EVEN BE BOTHERED TO WRITE A
REASON FOR THEM!

There are two back-merges in that tree, and while they both merge
reasonable merge points (v4.14 and v4.15 respectively), neither of
them has *any* explanation of why the f*ck the merge was done. The
v4.15 merge doesn't even make it clear that it merges v4.15 - it just
says "master".

Having random commits with no explanation of what the hell they are
doing is NOT OK. It's not ok when they do real changes, but it's EVEN
MORE not ok when they are just random merges that bring in
who-the-hell-knows-what.

Merge commits need explanations of what they merge and why they merge it. This:

    Merge branch 'master' of
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/torvalds/linux

(which is all the explanation there is in commit ddb9e13af3bb) is
simply not acceptable.

At least the other merge merged the v4.14 _tag_, so just looking at
the merge it's at least clear that you merged a real release. It still
doesn't explain _why_ it was merged.

If you cannot state a good reason for the merge, or you can't be
bothered to write one, DO NOT DO THE MERGE.

It's really that simple.

          Linus "grumble" Torvalds