[lkml]   [2008]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Slow DOWN, please!!!
    On Thu, 01 May 2008 01:42:59 +0400
    Dmitri Vorobiev <> wrote:

    > Andrew Morton __________:
    > > On Wed, 30 Apr 2008 13:31:08 -0700 (PDT)
    > > Linus Torvalds <> wrote:
    > >
    > >>
    > >> On Wed, 30 Apr 2008, Andrew Morton wrote:
    > >>> <jumps up and down>
    > >>>
    > >>> There should be nothing in 2.6.x-rc1 which wasn't in 2.6.x-mm1!
    > >> The problem I see with both -mm and linux-next is that they tend to be
    > >> better at finding the "physical conflict" kind of issues (ie the merge
    > >> itself fails) than the "code looks ok but doesn't actually work" kind of
    > >> issue.
    > >>
    > >> Why?
    > >>
    > >> The tester base is simply too small.
    > >>
    > >> Now, if *that* could be improved, that would be wonderful, but I'm not
    > >> seeing it as very likely.
    > >>
    > >> I think we have fairly good penetration these days with the regular -git
    > >> tree, but I think that one is quite frankly a *lot* less scary than -mm or
    > >> -next are, and there it has been an absolutely huge boon to get the kernel
    > >> into the Fedora test-builds etc (and I _think_ Ubuntu and SuSE also
    > >> started something like that).
    > >>
    > >> So I'm very pessimistic about getting a lot of test coverage before -rc1.
    > >>
    > >> Maybe too pessimistic, who knows?
    > >>
    > >
    > > Well. We'll see.
    > >
    > > linux-next is more than another-tree-to-test. It is (or will be) a change
    > > in our processes and culture. For a start, subsystem maintainers can no
    > > longer whack away at their own tree as if the rest of use don't exist.
    > > They now have to be more mindful of merge issues.
    > >
    > > Secondly, linux-next is more accessible than -mm: more releases, more
    > > stable, better tested by he-who-releases it, available via git:// etc.
    > Andrew, the latter thing is a very good point. For me personally, the fact
    > that -mm is not available via git is the major obstacle for trying your
    > tree more frequently than just a few times per year.

    Every -mm release if available via git://, as described in the release

    The scripts which do this are a bit cantankerous but I believe they do

    <tests it>

    yup, 2.6.25-mm1 is there.

    > How difficult it
    > would be to switch to git for you?

    Fatal, I expect. A tool which manages source-code files is just the wrong
    paradigm. I manage _changes_ against someone else's source files.

    > I guess there are good reasons for still
    > using the source code management system from the last century; please
    > correct me if I'm wrong, but I believe that using a modern SCM system could
    > make life easier for you and your testers, no?
    > >
    > > I get the impression that we're seeing very little non-Stephen testing of
    > > linux-next at this stage. I hope we can ramp that up a bit, initially by
    > > having core developers doing at least some basic sanity testing.
    > >
    > For busy (or lazy) people like myself, the big problem with linux-next are
    > the frequent merge breakages, when pulling the tree stops with "you are in
    > the middle of a merge conflict".

    Really? Doesn't Stephen handle all those problems? It should be a clean
    fetch each time?

    > Perhaps, there is a better way to resolve
    > this without just removing the whole repo and cloning it once again - this
    > is what I'm doing, please flame me for stupidity or ignorance if I simply
    > am not aware of some git feature that could be useful in such cases.
    > Finally, while the list is at it, I'd like to make another technical comment.
    > My development zoo is a pretty fast 4-way Xeon server, where I keep a handful
    > of trees, a few cross-toolchains, Qemu, etc. The network setup in our
    > organization is such that I can use git only over http from that server.

    Don't know what to do about that, sorry. An off-site git->http proxy might
    work, but I doubt if anyone has written the code.

     \ /
      Last update: 2008-05-01 00:13    [W:0.039 / U:2.068 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site