Havard Eidnes <he%NetBSD.org@localhost> writes: > This actually touches on this quesition: what should be the > criterion for deciding that a rust update is "safe"? That's not > at all clear to me. > > Obviously, cutting a pkgsrc branch where the build of www/firefox > is broken because of rust on NetBSD/amd64 9.x would be very bad. > Probably the same can be said for NetBSD/i386 9.x, though perhaps > less so, particularly if the problem isn't actually caused by > rust. "caused by" is difficult. What I'm trying to say is that on platforms where firefox works before a rust update, it should work after a rust update. That's really straightforward, I think. It may be that we believe that if a rust package completes successfully there will be no problems with firefox and other things. In that case we don't need to test firefox any more. And, if the updates happen not in the last 2 weeks before freeze, it's all much easier since we have time to pick up the pieces. > However, we build rust on more ports/targets which either has > never managed to build firefox (looking at macppc and probably > armv7(?)), or where it's continually troublesome for mostly other > reasons (sparc64). Obviously "firefox builds" can't be a > criterion for those ports/targets. Certainly. But I've been trying to say "no regressions" not "can build firefox". > Borderline is probably NetBSD/i386 8.0 -- my recent attempts > revealed a needed fix for multimedia/dav1d (thanks, Nia!), and a > dubious construct trying to use a clang-specific option with gcc > for NetBSD 8.* in mozilla-common.mk. These obviously have > nothing to do with rust itself, but are indicative that this > particular port/OS-version combination doesn't get sufficiently > excercised. True. Again, if it was troubled before, it's not part of the rust-ok discussion. > Borderline is perhaps also NetBSD/aarch64(?) -- do we have > firefox building and working on that? The build resources I have > available are however inadequate to build www/firefox on aarch64 > in acceptable time, it's barely sufficient to test-build rust, > "natively". Not borderline as we just heard. And there is no requirement that *you* do all this testing. It is that it's happened. So I have been trying, perhaps not clearly enough, to say that after there is a proposed update in wip, then someone should send a note out to tech-pkg asking people to test it (by doing make replace and then building firefox). The key point is to have an update that is believed adequate, and to poke people that now is the time, vs having them randomly try something in wip that may or may not be believed ready. > A large user of rust is of course the rust compiler itself. If > there is a fundamental fallout for one of the ports/targets we > build for which would break firefox, would not that also prevent > the build of rust itself? Probably. But I am speaking with release manager hat, and we have gotten a lot of flak for missing firefox in the past -- including at least one time due to rust troubles -- and that leads me to want to actually test it, rather than float a theory that testing is not necessary.
Attachment:
signature.asc
Description: PGP signature