i'm not worried about that aspect: those developers either write perfect
code that never needs any tester or user assistance (in which case our
discussion is moot), or if it's buggy then these developers will
eventually be replaced with more capable people who are helping their
testers and users more actively by reading lkml and responding there.
What we must not do is to give in to the splintering and laziness and
actively _chase people away_ from lkml.
yeah, thanks, that will do fine.
_Helping_ subsystem maintainers become aware of problems and
cross-Cc:-ing to whatever preferred email alias they use (be that their
own mailing list address or netdev@) is a necessary and positive feature
of lkml: almost by definition the user has little idea about what is
wrong with their kernel, and if the mail is unspecific enough or labeled
incorrectly then it's easy for a maintainer to miss it. (It's already a
very good first step when user know that the problem area is their
kernel to begin with.)
Putting the "weight of initial discovery" on to the user on the other
hand is actively harmful. It will only result in users picking the wrong
list and being ignored there, upstream maintainers not getting a full
picture about what kind of per subsystem bugs people are experiencing,
etc., etc. The only thing that works in the long run is to make the
private development email aliases _opt-in_ feature, and to always have a
main body of information: lkml.
Ingo
--
