Re: Slow DOWN, please!!!

[Andrew Morton]

On Thu, 01 May 2008 01:42:59 +0400
Dmitri Vorobiev <dmitri.vorobiev@xxxxxxxxx> wrote:

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

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