Hi Dan, On Thu, 16 Feb 2012 13:49:53 -0800 (PST) Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxx
Attachment:
pgp1DQrWaEdQ1.pgp
Description: PGP signature
