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:   Tue, 17 Sep 2019 19:16:37 +0100
From:   Will Deacon <will@...nel.org>
To:     Jessica Yu <jeyu@...nel.org>
Cc:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Matthias Maennich <maennich@...gle.com>,
        gregkh@...uxfoundation.org,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Kbuild updates for v5.4-rc1

Hi Jessica,

On Tue, Sep 17, 2019 at 08:01:36PM +0200, Jessica Yu wrote:
> Yikes, I did not catch Stephen Rothwell's email about pausing the
> linux-next releases from Sept 5 until Sept 30
> (https://lore.kernel.org/linux-next/20190904233443.3f73c46b@canb.auug.org.au/).
> 
> The modules-next namespace patches have been in since last Tuesday,
> and my original plan was for them to catch at least a week of
> linux-next time before sending the pull request. :-/ But that did not
> happen due to the above.
> 
> So Linus, in light of the above realization, I'd say at this time - I
> will still formally send a pull request with the merge conflicts
> resolved with either solution #2 or #3, but merge at your own
> discretion, it's fine to delay to the following release if you're
> uncomfortable.

FWIW, when I've run into unexpected merge conflicts with other trees in the
past, I've found that it's usually sufficient just to include the resolution
as an inline diff in the pull request, rather than try to munge the tree
with merges or rebases.  Linus is pretty good at figuring it out, and with a
resolution to compare with, the damage is limited. The downside of the merge
is that it's fiddly to extract the changes and see what's actually being
pulled.

Also, it's not like the kbuild stuff has been in -next for ages, so this
would've been a late and messy conflict regardless.

Will

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ