On Tue, 04 Mar 2008 17:51:22 +0000 David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > On Tue, 2008-03-04 at 09:59 +0100, Jim Meyering wrote: > > David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > > > I'm concerned that switching back to 4KiB pages is just papering over > > > real bugs to make life easier for PPC folks. I suspect that what I > > > should _actually_ do is keep it 64KiB, brazen it out and LART people who > > > just exclude ppc builds without actually looking at the problem for > > > themselves. But I'm lazy too... maybe we should switch the x86_64 > > > builders to 64KiB instead? :) > > > > > > Opinions? > > > > I'm surprised there's so much debate. > > Isn't it obvious? A service that finds generic bugs -- and ones > > that would likely be much harder to diagnose in any other context. > > People will complain no matter what you do, so take the high road: > > > > Brazen it out with a LART :-) > > The problem is that there is a risk that it'll make the less > conscientious packagers just think 'oh, building for ppc is painful' and > exclude that architecture. There's enough of that already, with some > people even sticking to that line even after the same bug bites them on > x86_64 too. > > That's not _such_ an issue because there are relatively few such > packagers, and we have the rule that all architecture exclusions _must_ > be filed in bugzilla and we can keep track of them through the > ExcludeArch tracker bugs. > > My _real_ concern is that continuing to use 64KiB pages is likely to > increase the motivation for people to let PPC builds fail _without_ > aborting the main build on x86/x86_64, so the laziest of packagers don't > even have to _look_ when their build fails. And then a lot of the > benefit is lost (or we just start pushing even more of the generic bugs > onto the arch team and making it really hard for them to keep in sync > with the development tree properly). > > Yes, that would be extremely misguided, but I think it's dangerously > likely to happen and I don't want to make it _more_ likely or accelerate > it. My biggest concern is that it doesn't match Fedora, which makes it harder for people who _do_ care to actually reproduce the issue and debug the problem. Local mock builds on a Fedora PPC system would use 4KiB pages and would likely build/test just fine. Reproducibility is fairly important IMHO. If we have a ppc64 machine running a RHEL kernel for people to log into to do mock builds, etc my concerns are lessened slight. But I really think we should be eating our own dog food here. josh -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list