[lkml]   [2011]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT PULL] Namespace file descriptors for 2.6.40

    * James Bottomley <> wrote:

    > Traditionally, the arch trees tend to go a bit later because they wait to see
    > if there's any fallout from x86; [...]

    Not really - most of the arch trees 'traditionally' went late even when the x86
    tree itself was monolithic and was itself sent late in the merge window (with
    the notable exception of the powerpc tree).

    > [...] but this time, I think it looks OK, [...]

    That's not really a surprise, there hasn't been a serious 'problem' with the
    x86 tree for a long time, roughly since we switched to the finegrained Git
    topical split-up maintenance model about two years ago.

    [ That split-up also means that there is no 'x86 tree' anymore as such: if you
    check lkml we send roughly 20-30 independent trees in the merge window and
    have done that for the past ~10 kernel cycles. ]

    In fact exactly *because* there's few problems with the x86 topic trees can we
    push them so soon: if problems were frequent then 1) we would not be able to be
    ready on time and 2) i suspect we'd be pulled in later in the window as well as
    a maintainer generally wants to pull low risk items first, high risk items
    last, to maximize the utilization of testing capacity.

    I agree with Linus's notion in this thread though, a core kernel change should
    generally not worry about hooking up rare-arch system calls (concentrate on the
    architectures that get tested most) - those are better enabled gradually

    Also, system call table conflicts are trivial to resolve. Merging in net-next
    to avoid such a conflict is like cracking a nut with a sledgehammer.



     \ /
      Last update: 2011-05-22 10:45    [W:0.044 / U:7.440 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site