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

Stir up some controversy!

[levendis]

Forget the traditional route of submitting a bug report and waiting for Linus to accept it... instead, write a quick, half-assed article for ZDnet or Cnet about the major Linux bug/vulnerability you've found, and the resulting controversy will certainly grab the developers attention. I'm sure the now-infamous Mindcraft web benchmarks had something to do with the fact that kernel 2.4 includes a fully revamped, SMP-aware TCP/IP stack.

Seriously, though, Linux does need some sort of central bug repository, and this type of thing was recently address by ESR himself in a linux kernel mailing list post. For Linux to continue as a strong player in the Server OS market, some level of professionalism and organization must be achieved...

Getting the attention of developers

[Shoeboy]

Ok, it's really easy to get the attention of developers. You just need to figure out where they hang out.
The kernel mailing list is a bad choice since it's read by thousands of M$ spies. The kernel developers know this, so that's why they post misleading and erroneous mailings there. It's all about subterfuge.
So if they're not on kernel-dev, where are they?
Simple you moron, they're reading slashdot. They use /. as a covert channel to discuss the kernel. You haven't noticed since they use steganography to hide their messages from m$. It's true - vladinator is actually hans reiser, spiralx is alan cox, trollaxor is ingo molnar and magenta syringe is linus.
They use the   entities and goatse links to communicate in a form of morse code. Try viewing source - it's informative.
Anyway, now that you know where to find the kernel developers, you need to get their attention. This is easy since linux hackers are only interested in one thing: Natalie Portman.
(note for the confused, Natalie Portman used to be the code word for the rewrite of the scsi subsystem in 2.4, but it was causing too much of a problem with spontaneous orgasms, so they switched to olsen twins this is why osm *actually davem@redhat.com* used to post about it all the time.)
At any rate, claim that you have nude photos of Natalie Portman and you'll get their attention. Now that you've got their attention, post a link to the Portman pix that points to goatse.cx. This will let them know that you want to participate in kernel development. Now you wait. They'll contact you and integrate your patch.
--Shoeboy

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.

The "contributions from unknown sources" problem

[alienmole]

> I realize that my posting to linux-kernel, linux-scsi, linux-net, and net-dev hasn't been prolific, and thus, my name probably doesn't stand out to the main developers when I do post, but I always thought that one of the points of the hacker/open source "community" is that it's based on what you're doing now, not what you did in the past, or how good you are at self-promotion.

I think this is one of the central issues: if the developers don't recognize your name, they don't have any way to assess the validity of what you've posted, other than potentially spending significant time reviewing your bug or patch. You might think you've found an esoteric bug, and even fixed it, but you might be completely wrong (and this does happen, I've seen it.) Or, your fix might be undesirable in some way. Or, it just may not be that important - if no-one else has reported it, and there are hundreds or thousands of other problems known to affect thousands of people, which ones should be fixed first?

After all, the people intimately involved with the kernel can't be expected to, and shouldn't, automatically apply every patch posted to the list. There needs to be some review. The problem in the case mentioned in the article is really that the developer didn't catch the attention of anyone willing to take the time to review his patch. Instead of throwing it out there, he could perhaps have tried to find the person or persons most likely to be familiar with the problem he was addressing, and ask that person directly if he would be willing to review his patch.

Open Source and/or Free Software requires intelligent actions amongst its contributors. Throwing a patch or bug report over the wall doesn't necessarily count.

Use a descriptive, eye-grabbing subject line.

[Chyeburashka]

As you know, lkml traffic is now between 150 to 200 messages a day. I looked through the archives, and I might suggest the following subject line for your submission on 6-21-2000:

[PATCH] Fix to watchpoint problems in traps.c

The patch in your 6-23-2000 submission (at least in the kernel mailing list archives) is not in the form typically used, namely the output of diff.

Please don't be discouraged, and try again.

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.