linux-kernel - [Tree, v2] De-clutter the top level directory, move ipc/ => kernel/ipc/, samples/ => Documentation/samples/ and sound/ => drivers/sound/

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20190924113135.GA82089@gmail.com>
Date:   Tue, 24 Sep 2019 13:31:35 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Borislav Petkov <bp@...en8.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>
Subject: [Tree, v2] De-clutter the top level directory, move ipc/ =>
 kernel/ipc/, samples/ => Documentation/samples/ and sound/ => drivers/sound/


* Ingo Molnar <mingo@...nel.org> wrote:

> Oh, that's a pleasant surprise, I didn't expect _100%_ support! :-)
> 
> So I started working on this today and whipped up three of these 
> movements, in a 100% scripted fashion.
> 
> You can have a sneak preview at the result in this tree:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.core/toplevel
> 
>    ...
> 
>    2515 files changed, 42476 insertions(+), 42476 deletions(-)

I have pushed out a -v2 version:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.core/toplevel

   2523 files changed, 41304 insertions(+), 41302 deletions(-)

Changes relative to -v1:

 - Fixed a bunch of bugs that light testing and light review missed: 
   missed rename patterns and some build bugs as well. This tree has 
   passed much wider testing, including cross-platform build testing, a 
   distro kernel package build and it also got some light boot testing, 
   just in case.

 - Split it into finer grained steps (3 instead of 2 patches per 
   movement), for easier review and bisection testing:

     toplevel: Move ipc/ to kernel/ipc/: move the files
     toplevel: Move ipc/ to kernel/ipc/: adjust the build system
     toplevel: Move ipc/ to kernel/ipc/: adjust comments and documentation

     toplevel: Move sound/ to drivers/sound/: move the files
     toplevel: Move sound/ to drivers/sound/: adjust the build system
     toplevel: Move sound/ to drivers/sound/: adjust comments and documentation

     toplevel: Move samples/ to Documentation/samples/: move the files
     toplevel: Move samples/ to Documentation/samples/: adjust the build system
     toplevel: Move samples/ to Documentation/samples/: adjust comments and documentation

 - The changes are now bisection safe if the #1 ('move') and #2 ('build 
   system') patches are squashed. The final #3 'adjust comments and 
   documentation' patch is non-functional in the normal kernel build.
   I still kept the three steps separate, for reviewability: for many of
   the changes the build system changes are lost in the noise of the 
   file movement diff itself. (See patch-splitting notes further below.)

 - Made some of the build system changes less ad-hoc - but it's still all 
   100% scripted and automated. Added a SOB to the changelogs, but the 
   changelogs are still barebones. It's on top of Linus's latestest.

 - The longer term plan outlined in my first mail is still in flux - the 
   'scripts/' movement is probaly a bad idea due to its widespread use.

I'm still torn about whether to do a 3-part or 2-part approach for each 
directory movement:

 - The problem with the 2-part approach that merges the 'pure file move' 
   and 'build system' patches so that the latter gets lost in the first 
   one in an almost unreviewable fashion. Someone would have to re-do the 
   git mv step and generate a diff by hand to see the build system 
   changes in isolation...

 - The problem with the 3-part approach is that it breaks bisection 
   between the first two patches, although 'git bisect next' would always 
   step to a working commit, because the bisection build-breakage window 
   is only one commit wide.

So I'm slightly leaning toward the 3-part approach for the documentation 
and review value - but no strong feelings either way.

Anyway, I know everyone is super busy with the merge window, will keep 
posting new versions every now and then until you or Linus tells me not 
to bother :-)

Thanks,

	Ingo