Hi Dan,

On Thu, 16 Feb 2012 13:49:53 -0800 (PST) Dan Magenheimer [off-list ref] wrote:

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?)

From my daily release note:

"Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary."

So yes, I build between each merge.  It allows me to isolate where
problems are occurring so that they can be easily fixed in isolation.

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.**

Yes, I can do that (and will for today).  However, it does mean that the
staging tree now cannot be merged into Linus' tree until after the tmem
tree has been merged.   And if Linus decides not to take it, then Greg
will have to remove these commits from his tree (or revert them) before
he can get all the rest of the staging tree into Linus' tree.

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

Of course it makes sense - at least at the "make sure it builds" level.

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.

Maybe you should seek a dispensation from Greg to allow your ramster tree
to exist independently in linux-next and be merged independently by
Linus'.  Greg may want to keep watch in your tree, but that should not be
much more effort than reviewing and applying your patches to the staging
tree.

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.

Definitely.

I do realise that the staging tree is "special", but I am trying to deal
with this in a generic manner (as I would for dependencies between any
other two trees).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au