On 01/22/2018 09:30 PM, Hadrien Grasland wrote:
In Mozilla's terminology, "tier 2" means "guaranteed to build" and "tier 1" means "and in addition, all automated tests were run". The reason why you would want to only run the build is that running tests is much more trouble than building, because you can build for any architecture from x86 using a cross-compiler, whereas you need real hardware on the target architecture in order to perform serious testing (as emulators are usually too slow to be practical in intensive testing scenarios, and too "clean" to expose real hardware quirks).
See, and that is the difference with downstream distributions. They use real hardware to build **and** run the testsuite.. In Debian, cross-building, for example, cross-building is not allowed for the supported release architectures for very good reasons. What you are saying is not a justification, it's merely an explanation. Go upstream, for example, runs the builds and testsuites on all their supported platforms natively. They do not accept ports for which this criteria cannot be met: https://build.golang.org/ Any supported target which is unable to pass the testsuites for a longer period is dropped from Golang. They take testing and integration much more seriously than Rust does.
Assuming you wanted to build yourself a cross-architecture test farm, capable of withstanding the full traffic of Rust's high-volume CI system, what you would soon discover is that most hardware architectures do not address this need very well. It is trivial to find a hardware reseller who will build you a good x86-based rack at a fair price, whereas other architectures often do not provide hardware in a standard rack form factor at all, or only sell hardware at a crazy premium like IBM does with Power. Moreover, embedded architectures also often restrict themselves to cheaper and slower hardware which is not powerful enough for intensive continuous testing, meaning that you need to pile up tons of un-rackable junk before you get enough processing power for this kind of use case...
We have that in Debian. I'm not sure why you are trying to educate me here.
Add to this that keeping a highly heterogeneous hardware base running is very cumbersome, and that some of Rust's tier 2 architectures do not even provide the required capabilities for running a test server (e.g. asmjs/wasm is too limited, Fuschia is too immature, and iOS is too much locked down), and hopefully you will get a fair picture of how much of an undertaking this all really is.
Again, look at this:
https://build.golang.org/# https://jenkins.debian.net/view/rebootstrap/ https://buildd.debian.org/status/package.php?p=gcc-7&suite=sid
You are talking to someone who is working as a build engineer at Debian.
Now, this isn't to say that it cannot be done, of course. Nor that it would not be very worthwhile. There are some awesome multi-architecture test beds out there, like Debian's package QA test bed or Microsoft's driver compatibility torture test farm, and I'm pretty sure Novell also have some cool stuff around for testing SuSE too. But I think that level of QA sophistication may be a bit much to expect from a relatively small team inside of a money-starved nonprofit organization. If someone is ready to donate or lend Mozilla the required infrastructure, great, but if not, I would not expect them to build it on their own...
Maybe Mozilla should understand at some point then that they're not Google.
We have just recently seen with Spectre and Meltdown how bad it is to merely focus on x86.
I think you may want to check the latest developments of the Meltdown/Spectre saga here. Meltdown, it turns out, goes beyond Intel processors (AMD remaining unaffected) and also hits some high-end ARM processors. And Spectre attacks have been demonstrated on pretty much every modern CPU which has a cache and speculative execution features. It is not an x86 versus the rest of the world thing, almost every popular high-performance CPU architecture has been demonstrated to be vulnerable to these attacks in some way, and all high-performance CPU manufacturers now needs to reflect upon these events and figure out how to build a more secure product next time...
https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre...
PS: I have patches both in Rust upstream and Mozilla (around 30 patches) upstream before you again are trying to paint me as someone uneducated on the subject. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org