David Woodhouse wrote:
The arch team pick it up when more arch-specific clue or porting work is required, with assistance and pointers from the package maintainer. More clueful maintainers can handle a little more; the less clueful fall back to filing a bug and calling in the arch team a little sooner -- some may even call in the arch team just to help whittle down a test case for a compiler bug report, But the balance works well.
And auto filing bugs will let more people know about this sooner. Maybe the maintainer fired off some builds at night before bed and they failed but there are other people awake and just happen to take a look and troubleshoot it. They might be able to have a solution ready before the maintainer wakes up in the morning. I don't see how the auto-filing of bugs is a bad thing.
I'm very concerned that if we allow partially-failed packages to make it into the repo, even with an automatic bug filed, that will encourage the less conscientious maintainers to not even bother to _look_ at a failure which may also affect other architectures. And we get into a situation where it's considered 'normal' for some packages to be missing on some architectures without good reason.
We need to counter this. One possible way is to file the bug against the maintainer rather than the arch team. This way they need to look at the issue still, and decide "I don't know WTF this means" or "ExcludeArch" or whatever.
Also, the automatic bugs will lack the information which the arch team would want from the maintainer about what's going on, anyway.
Not if the maintainer is assigned the bug initially and he then comments (which he ought to do on bugs assigned to him). I think that's a fair compromise.
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
