lkml.org 
[lkml]   [2008]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Slow DOWN, please!!!
On Thu, 01 May 2008 01:42:59 +0400
Dmitri Vorobiev <dmitri.vorobiev@gmail.com> wrote:

> Andrew Morton __________:
> > On Wed, 30 Apr 2008 13:31:08 -0700 (PDT)
> > Linus Torvalds <torvalds@linux-foundation.org> 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
announcements.

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

<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    [from the cache]
©2003-2011 Jasper Spaans