On Wed, 2007-07-11 at 16:58 -0500, Tom "spot" Callaway wrote: > I'm still not convinced this is necessary. I think this puts too much > burden on the maintainer, when this should fall to the secondary > architecture team. I think you're mistaken on both counts -- on where the responsibility is likely to lie, and on the amount of this 'burden'. My experience is that _most_ such failures are going to turn out to be generic bugs in the package; not really arch-specific problems at all. They'll bite on more than one, if not all, architecture(s); if not immediately then over time. It's just that some bugs don't show up 100% of the time; they're dependent on subtle things like the number of CPUs, the amount of memory available, how the compiler chooses to lay out registers, etc. Shipping the affected packages without even expecting the maintainer to _look_ at the failure is a very bad idea, from a QA point of view. It's also an unreasonable thing to do to the arch team for the affected architecture(s) -- both because we're making them take on the initial investigation of bugs in arbitrary packages which are likely not to be arch-specific at all, and because we'd be making them deal with the build system inconsistencies which arise from the unnecessary missing packages; just as Jesse reminded us only worse. And the 'burden' of which you speak is _trivial_ -- you spelled it out yourself. We're talking, in the minimal case, about the amount of time it takes to _glance_ at the build failure (for a package you _know_) and make a decision about whether or not you care; whether your build is so urgent that it has to be shipped now without waiting for a fix; whether the secondary arch in question is going to be screwed by the absence of the updated package because you're about to build a dozen other packages against it, or whether it's a 'leaf' package which doesn't really matter, etc. Let the maintainer make that decision; really. It'll work out right -- the people who maintain the core packages are in general more conscientious than those who maintain only leaf-node packages, and will tend to do the job properly where it matters. I know you're worried about the lowest common denominator; the people who don't even understand the language which their package -- the package which they're supposed to be supporting and fixing bugs in -- is written in. But that's fine -- all they have to do is file an empty bug saying "the build failed but I do not know anything about why", and push the "ship it anyway" button. It sucks that we have such poorly supported packages, but it doesn't really hurt the secondary architectures much more than it hurts anywhere else. They'll generally not be packages we depend upon for much. It just isn't that much of a burden, for those who don't want it to be or who aren't up to the task. It only helps to set expectations, and stops us from _automatically_ shipping something which is actually quite likely to be broken on the primary architectures too. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
