[Ksummit-2012-discuss] [ATTEND] structuring of tools et.al and linux-devel.git repo

[Steven Rostedt]

I'll follow Greg KH's example, and even though I'm on the program
committee too, I will also submit a proposal for my request to attend.

1) Restructuring of directories in the kernel repository.

I mentioned in another email that I find the scripts directory quite a
mess. People keep suggesting that kernel scripts should go there, but
most of the code there is for the kernel build process. depmod.sh and
headers.sh are not the same type of script as checkpatch.pl. I
suggested:

mv scripts build/
mkdir tools/scripts
mv build/<non-build-scripts> tools/scripts

Joe Perches reported that a tools/scripts currently exists (and it does)
but it too is used for the building of the tools directory.

That too should be renamed to tools/build.

This way tools will be where things that are not part of the kernel or
the kernel build process can go.

The tools/scripts can grow to hold helper scripts used by different
maintainers such that each of them is no longer reinventing the wheel.

We also have a tools/lib that will hold libraries that can be used by
not only other tools programs, but also packaged for tools that live out
of tree. For example we are making a libtraceevent.so that distros could
package separately for things like powertop to use. Perf and anything
else that resides in tools can still statically link to these libraries
to be a standalone.

I'm wondering if there will be distro packagers that would like to give
their input to let us know the best way to setup these directories so
that it makes their job easier to package the libraries as well as the
tools.


2) Creating a linux-devel.git repo

Some of the discussion so far has been about code getting into Linus's
tree without going through linux-next. Or changing between the two. I
would like to suggest adding a linux-devel.git repo that would let
anyone that requests to add their development code to this repo. It may
even spot duplicate work that is going on, or a place to house competing
projects where it will be easier to do comparisons.

If a pull causes the build to break or to break others code, then it
will be reverted (not pulled), and a nasty email will be sent to the
maintainer to fix it.

Rebases will be allowed, and even encouraged. No one should be basing
their work off of this tree, but they can use this tree to test their
work against other development code. I want this to be like the old -mm
tree was.

When your code has been vetted by the linux-devel repo, you can then
push it to the linux-next repo. Ideally, your code will be good enough
that it would no longer need to be rebased when it gets there, and the
linux-next code will be ready for Linus to pull.

I believe a repo like this will get new development code more exposure
and may even find bugs before it gets to the linux-next stage. Maybe
even give better review. If a developer notices something different
(good or bad) with how their system is working, if they can spot the
cause it can be reported to the maintainer of the developmental work.
This will leave less surprises when code goes mainline.

-- Steve