lkml.org 
[lkml]   [2011]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

    * 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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-11-10 08:51    [W:4.229 / U:0.120 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site