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.