On 12/21/2010 2:12 AM, Loïc Minier wrote: > Upstream faces the same problem, yet manages to move the compiler > forward. Since Linaro's goal is for all new developments to make it > upstream, we should simply live by upstream's standards when developing > patches.
However, Linaro doesn't have upstream's resources. In the context of upstream, if you post a patch that works on (say) ARM, but breaks on (say) SPU, then it's your obligation to fix that problem. But, you generally have the combined resources of upstream, including a lot of expertise from maintainers of other architectures to draw on. In Linaro (despite the fact that we have Ulrich Weigand, a very talented Power developer, and Richard Sandiford, an equally talented MIPS developer), we do not have the breadth of knowledge that we have upstream. So, I'm questioning the objectives. Linaro isn't upstream. It's not a multi-architecture consortium. It's all about ARM. Therefore, a multi-architecture distribution that wants to provide best-in-class tools for all architectures cannot rely completely on Linaro; there will be important patches for MIPS, Power, x86 and other architectures that are not going to be incorporated into the Linaro sourcebase. I'd rather the criteria for Linaro be that the Linaro sourcebase work well on ARM. Of course, we should submit patches upstream as well. In that process, the patches will change, to better support other architectures, or otherwise. We can backport those changes, or we can just wait for our next merge from upstream, and get them then. This would give Linaro the clearly focused mission of providing excellent tools for ARMv7-A. My two cents, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
