How Can One Attract the Developer's Attention?

James Cownie asks: "The Linux kernel development is an open process, we all know that, but, as an unknown in the community it seems impossible to attract the attention of anyone on the kernel list. I'm not trying to reimplement huge kernel subsystems or do anything major, but I found a genuine kernel bug, documented it and submitted a patch on the kernel mail list; to be met with complete and utter silence. Just as if no-one had read my mail at all. I can stand and react to abuse, or requests to fix my patch, or whatever, but what can I do in response to silence?" UPDATED

"I can't mail Alan Cox (who seems the right person for a fix to 2.2) directly because he rejects all mail from folks he doesn't know. Since the bug causes problems for gdb I mailed the gdb developer list, but also met with silence. So, how can I get someone to take notice? If no-one does, what's the point of an 'open' process? I may as well not bother."

First off, a good deal of patience is necessary when dealing with developers, they can be extremely busy when it comes to dealing with the pressures not only from their day jobs, but also from their code, their other hobbies and whatever time is left over for them to have lives to themselves. Even on internet time, certain things (like bug reports) will slip thru the cracks and seemingly fall into the ether...a few times, this might be the case, most often though, it is not and the developer just hasn't gotten to your bug/comment/suggestion yet.

A suggestion to developers: If you haven't looekd into this, it might not hurt to automate some form of reply stating your situation so that you don't alienate users by your non-response.

Thoughts?

Update: 09/05 11:50 PM by C : Alan Cox had this to say via email:

"I can't mail Alan Cox (who seems the right person for a fix to 2.2) directly because he rejects all mail from folks he doesn't know."

This is wrong. I reject mail from sites in ORBS, RBL or other major spam block lists.

A few things I'd suggest:

1. There is a REPORTING-BUGS file in 2.2/2.3 kernels
2. You should start with MAINTAINERS in the kernel for kernel bug reports
3. If its a vendor supplied kernel start with the vendor bug report system such as http://bugzilla.redhat.com/bugzilla [for Red Hat]. ( C : There's also Debian's bug reporting system at http://www.debian.org/Bugs, and the one for Mandrake-Linux at http://www.linux-mandrake.com/bugs, for other flavors of Linux, check your vendor's homepage)

#3 is important. Vendor kernels rarely match the default due to timing issues, desire to ship stuff like USB, Reiserfs, 3D acceleration and more."

As I said, the developers are listening. You just might need to take the time to find the right communication channel. For a bug report to be worth something, it has to end up in the right place.

Comments

Patience...

[Garpenlov]

Whether or not he was going about it the right way, it looks like he has been plenty patient.

http://www.geocrawler.com/arch ives/3/35/2000/6/0/3875772/

This is from June, and the post indicates he posted the bugfix in December of 1999.

Don't get discouraged!

[Phaid]

I had this experience myself a few months ago - I was having a problem compiling 2.3.48 and .49 with Athlon-specific kernel features turned on. I wound up fixing the problem - it was trivial - and posted this patch to the mailing list.

No one got back to me directly, and indeed it took two revisions of the kernel (but at that point they were coming out about twice a week) to get the fix "officially" in.

But, on the other hand: a lot of people were happy that I posted the patch, and the fix did eventually get included -- or at least, the problem got noticed and someone fixed it, albeit a different way.

The moral of the story: the developers don't have time to answer every email personally, but posting problems - and patches - to the list will help others and it will cause the problems to eventually get noticed and fixed.