is there any particular reason why you cut out the most relevant part of
my reply, which happens to answer all your questions AFAICS:
had you read this portion you'd have realized that i did not search for
any "owner" of the file, i simply searched for the person who introduced
the change, and the on-lkml mail where the change was introduced.
and that's all that should be needed, really. Believe me, i hit tons of
bugs all across the kernel, often several bugs a day, and it's hard even
for me to figure out who "maintains" a file and when. (and in Linux
there's no "ownership" of files anyway) So as a general rule i go after
changes instead, and that's exactly what i did here too. I do
delta/regression QA - i.e. i watch for _changes_ that break the kernel
and hence the general 'owner' of a file is often irrelevant - it's the
maintainer who introduces a change who matters, and we do lots of
cross-maintain merges. Only if i do not manage to identify a change do i
try to figure out who maintains a file at that given moment. (But those
mails often go into black holes, they get bounced, subscriber-required
email lists, etc. etc.) It's also nontrivial to map the files to the
MAINTAINERS file, and it's also quite outdated in some portions. So the
MAINTAINERS file is the last resort i use.
so i'm still totally befuddled why you think that there was anything
particularly wrong or unhelpful about me replying to the specific pull
request that introduced a particular breakage into the kernel. Had i
mailed to lkml with a terse "kernel build broke" message with just an
URL to a config and the build breakage, you could rightfully have
complained that i should have done more to properly direct my bugreport.
But this breakage was about a PCI API change, the pull request had a PCI
mailing list Cc:-ed, why should i have thought that this needs the
attention of any other parties?
Ingo
--
