From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
Subject: Re: linux-next: build failure after merge of the staging tree

Hi Dan,

Hi Stephen --

Thanks for the reply and sorry for the hassle.  See below for
important question.

quoted

which changed the names of those fields from "flush*" to "invalidate*".
I am the author of that commit but it is pulled through Konrad Wilk
(cc'ed). Perhaps Konrad's pull succeeded in next-20120214 but
failed in next-20120215?

If a fetch fails for a particular tree on a particular day, I use the
version of that tree from the day before, so that is not the problem (and
in any case, the fetch did not fail).

quoted

Kernel.org seems to be down so I can't see if that commit is
in next-20120215 but if it is not that would likely cause
the above errors.

It is in next-20120215 (and has been since next-20120124).  However, I
merge Konrad's (tmem) tree *after* I merge the staging tree, so that commit
was not present when I tried to build linux-next after merging the
staging tree.

Huh?  Do you do allyesconfig/allmodconfig build testing after you pull
each individual tree or only after all trees are pulled?  (Apparently
the former, as otherwise the ordering shouldn't matter, right?)
 

quoted

The good news is that there seems to be an increasing number
of people contributing to and building things on top of
cleancache/frontswap stuff.  The bad news is that it is difficult
to avoid ordering dependencies that affect -next.  My apologies
and if you have any dependency-savvy processes that would solve
this that we are not using, please let me/us know.

Well, if anyone had bothered to tell me, I could have reordered the
trees.  However, that does not change the fact that the staging tree is
now broken on its own.  Which means that Greg can't even do unit testing
on his tree with your code in it. :-(

If you are doing the after-every-individual-tree build testing,
yes, if you could pull konrad's tmem tree first, that would
solve this problem I believe.**

I suspect unit testing doesn't make much as much sense in staging
as it does in the core kernel.  I did testing of ramster in my
public git tree (which includes the tmem patchset coming to you via
konrad) but, since it is a staging driver, the bits have to go
through Greg.

One solutions is for Greg to merge Konrad's tree (or a subset of it) into
the staging tree.  Another is for this work to become a separate tree
(however, I think other stuff in the staging tree depends on this work,
right?).

Yes, there are a number of parts from different companies/timezones
now flying in close formation.  The name change (flush->invalidate)
causing this problem was insisted upon by Andrew Morton (and has been
in linux-next for several months), otherwise it wouldn't have happened
and wouldn't be causing these issues :-(  But better to work through
them in -next than in Linus' merge window I guess.

Thanks,
Dan

** I just found another problem that occurs with allmodconfig
so will be submitting a patch for that to GregKH shortly and
will cc you.