Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

[Ingo Molnar <mingo@elte.hu>]

* Américo Wang <xiyou.wangcong@gmail.com> wrote:

> On Tue, Nov 8, 2011 at 5:32 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > So i think you should seriously consider moving your projects 
> > *into* tools/ instead of trying to get other projects to move out 
> > ...
> >
> > You should at least *try* the unified model before criticising it 
> > - because currently you guys are preaching about sex while having 
> > sworn a life long celibacy ;-)
> 
> Ingo, this is making Linux another BSD... manage everything in a 
> single tree...

It's not an all-or-nothing prospect. Linux user-space consists of 
well in excess of 200 MLOC code. The kernel is 15 MLOC.

I think the system-bound utilities that 'obviously' qualify for 
kernel inclusion are around 1 MLOC in total size, i.e. less than 0.5% 
of all user-space.

> Also, what is your criteria for merging a user-space project into 
> kernel tree?

Well, my criteria go roughly along these lines:

 1) The developers use that model and are productive that way and 
    produce a tool that has a significant upside.

 2) There's significant Linux-specific interactions between the 
    user-space project and the kernel.

 3) The code is clean, well designed and follows the various
    principles laid out in Documentation/CodingStyle and
    Documentation/ManagementStyle so that it can be merged into a
    prominent spot in the kernel tree and the project is ready to
    live with the (non-trivial!) consequences of all that:

        - the project does -stable kernel backports of serious bugs

        - the project follows a strict "no regressions" policy

        - the project follows the kernel release cycle of 'Winter', 
          'Spring', 'Summer' and 'Autumn' releases and follows the 
          merge window requirements and implements the post-rc1
          stabilization cycle.

These are not easy requirements and i can well imagine that many 
projects, even if they qualified on all other counts, would prefer to 
stay out of tree than be subject to such strict release engineering 
constraints.

Also, the requirements can be made stricter with time, based on 
positive and negative experiences. Projects can 'die' and move out of 
the kernel as well if the kernel repo did not work out for them. As 
long as it's all done gradually and on a case by case basis Linux can 
only benefit from this.

Thanks,

	Ingo