On Wed, May 10, 2017 at 8:24 PM, Mike Ruckman <roshi@xxxxxxxxxxxxxxxxx> wrote: > On Wed, May 10, 2017 at 04:52:05PM +0200, Kamil Paral wrote: >> I don't really understand this, and I haven't read the meeting log, so I >> apologize if my questions are dumb. > > I was in the meeting, and I was confused - so your questions aren't > dumb. :) > >> Why would we dictate that Editions/Spins can't use different software on >> different architectures? It might make perfect sense to use browser X on >> x86_64 because it's very good, but use browser Y on i386 because of memory >> limitations of i386 arch (browser Y needing much less memory than browser >> X). Similarly, if shell A no longer supports i386, why would be ban it from >> being preinstalled on x86_64? i386 would have shell B instead. Those are >> random examples, but it seems to me that they can be completely valid. If >> there's such requirement that Editions/Spins can't install different >> software on different arches, I think that should be established by FESCo, >> not us. > > I concur with Kamil on this one, I think there's valid reasons a package > set might be different based on the arch. If this is indeed the > direction we want to go, I think FESCo needs to make that call. FESCo has stated for alternate architectures to be considered "primary" that they should be the same and consistent as the other architectures for years (going back to F-18 or earlier) so for this to change now is inconsistent in what's been stated to date. We've been thumped numerous times for differences. >> For this particular Firefox example, what is the core problem that you're >> trying to fix here? Is it the fact that Firefox excluded many arches from >> builds? From my QA POV, since it excluded arm, it's a blocker, since arm is >> primary. If it hadn't excluded arm, it would not be a blocker, and >> alternate arches would need to find a way (fix the bug or use a different >> browser). If you still think this should not happen, you could ask FESCo to >> present some rules saying when Fedora packagers can exclude other arches >> from the build and when they can't. We could then enforce that (instead of >> prohibiting different package sets). > > As I think I said in the meeting, I thought the bug as filed was the > blocker and didn't see the need for the shadow bug created to track > blockeriness. It was a secondary affect, sure; but we deal with that all > the time. I concur that it might be a good idea to keep a list (FESCo > generated probably?) of "key" packages that need to be available on all > arches, or what arches they're allowed to not use. > > // Mike > -- > Fedora QA > _______________________________________________ > test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
