How Can One Attract the Developer's Attention? 64
"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:
This is wrong. I reject mail from sites in ORBS, RBL or other major spam block lists."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."
A few things I'd suggest:
- There is a REPORTING-BUGS file in 2.2/2.3 kernels
- You should start with MAINTAINERS in the kernel for kernel bug reports
- 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)
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.
Give 'em B33r!!! (Score:1)
*burp*
Re:Mailing lists. (Score:2)
Both of these systems allow a bug to be assigned, prioritized, and tracked. I know of many closed source companies (most of whom prefer to remain nameless) who use these systems as they are robust, reasonably mature, and don't cost a dime! Highly recommended. :)
--- Brent Rockwood, Senior Software Developer
Re:Quick and easy solution (Score:1)
hes using linus143@aol.com
No BugZilla for Linux kernels? (Score:2)
Re:I dont mean to be a dick but... (Score:1)
First of all this was not a major bug that presented a security risk. If it were, it would get due attention and be fixed in ample time. The reason why it was not attend to was because the Kernel developers were working on other more important stuff. The reason why many complain about Microsoft is because their *major* bugs which present security risks take a long time for them to fix. This is because they are busy adding features (which nobody wants) and Windows is (by its very nature) a less protected OS. I would also guess that the Windows code is more spaghettish. This guess also has to do with the nature of the OS, because the Linux kernel is monolitic while Windows is a microkerel system and it is more difficult to recognize and isolate the exact origin of a bug. Plus we all know Linux kernel hackers are just better programmers than those folks at Microsoft.
Re:BSD Style (Score:1)
Warning: (Score:1)
But wouldn't Bugzilla be a useful tool for the Linux kernel people?
That way, you wouldn't have to faff on with trying to get email to a small and select group of highly busy individuals, AND you could see if you were duplicating a bug that someone else had already reported...
--
I've had a response from Alan. (Score:2)
I wanted to amend the driver, but couldn't locate any maintainer. I emailed linux-kernel instead, asking who was in charge of the driver, in case anyone else had already fixed it, or anyone had the specs for this particular version of the card. Alan had worked on the module support for this driver sometime in the past.
The only one to respond was Alan, stating that the code wasn't currently maintained. We exchanged a few emails, when I decided to modify the driver. A few days later (having had to reload Windows95 to discover how the DOS driver worked), I produced a minor kernel patch and submitted it to Alan.
I got a very brief response, and around 2-3 months later the patch appeared in one of the 2.3.x kernel patches.
Just have patience...
The db6 bug is fixed in 2.2.17 (Score:1)
I'm thus surprised that this story appears now.
Re:Socialism And Capitalism. (Score:2)
Are you suggesting that those who get their patches included first are just somehow a bunch of good friends? I suppose it's a coincidence that they happen to each be (arguably) some of the best in the world at what they do then?
If it's closer to either, Linux development is closer to capitalism since you're more likely to get what you want (your patch included and the kernel fixed) if you can give the kernel gods what they want (proven track record of previous useful or insightful patches of design ideas) Compare these to getting what you want (a new car) because you can give them what they want (a good credit rating to show you are going to pay [compare with "show your patch will probably work])
Re:The db6 bug is fixed in 2.2.17 (Score:1)
No maintainer (Score:1)
Nobody owns that stuff. So a patch really has to fall through to Linus and he's nowhere near coping.
If James' patch was against something which had an active non-Linus maintainer then it wouldn't be a problem. I'd say that describes less than half the kernel.
The best approach would be to find someone non-Linus who understands that bit and work it with that person. Andrea, Pavel, someone like that.
Socialism And Capitalism. (Score:2)
OK, score me Flamebait for using the S-word again, but this is to be expected. In a capitalist system, the wealthy get things better, faster, etc. In a socialist system, there is the illusion of equality via the elimination of capital, but the fundamental laws of economics remain unchanged. You have just replaced dollar capital with social capital. What is social capital? It's how well connected you are, whether or not you are a member of the "3 initial club" or something like that.
Re:The db6 bug is fixed in 2.2.17 (Score:1)
Re:Reply to Alan's update (Score:1)
Re:And read the linux-kernel mailing list FAQ. (Score:1)
Re:Patience... (Score:1)
Not too bad, I think
Possible problem with patch submission (Score:1)
Just a thought. I only saw this garbaged up patch; I can see that you really do know how to submit a patch when the MTAs and MUAs cooperate. Good luck.
Re:Reply to Alan's update (Score:1)
Due to the amount of spam I get without ORBS filtering Im going to be implementing draconian filtering. Basically if you aren't someone who regularly mails me - tough you'll probably never get a reply now.
Re:The "contributions from unknown sources" proble (Score:1)
>the original email, in this instance, didn't even identify who should look at it
and
>if you don't make any effort to actually find someone who might be interested
Which is all fine, and I agree that if you don't put in effort you won't get a response, except that it's very _hard_ (verging on impossible) to find out who might be interested in this. The MAINTAINERS file doesn't mention this area of the kernel. The trap.c file doesn't have a maintainer listed in it. So, maybe I'm supposed to mail Linus, but that seems very unlikely, as the person at the top of the tree he's surely the most overloaded...
Re:Give 'em B33r!!! (Score:1)
We could probably arrange a Bristol Linux User group meeting too (in a pub !)
Vger dead? (Score:1)
Tired of corporate power? Vote Nader [votenader.org]
Re:BSD Style (Score:1)
The point is that FreeBSD, in particular, is under public revision control. Anyone can submit a patch to the project's GNATS database either via a web front-end [freebsd.org], or via send-pr(1) [freebsd.org].
The developers are of course free to ignore your PR, but it remains sitting there for the whole world to see until they either accept it, or tell you a good reason why they're not going to. :-)
Should your patch be accepted, the fact will also be noted for all time in the CVS repository [freebsd.org].
(It should be pointed out that the revision control extends beyond just the FreeBSD kernel, and covers the entire OS, including ports, documentation, etc. This also has many implications for the maintenance of FreeBSD systems. Want your ports and documentation to be up-to-date daily, and schedule a weekly update of all system sources and a rebuild? No problem.)
In fact, it goes even further than this. FreeBSD's development methodology is multi-tiered, with a central core team surrounded by a rather large group of committers. Not only does this mean that most submitted PR's are treated quite promptly, but it also implies that an active contributor with a good track record has a decent chance of becoming a committer, should he/she wish.
The original question pretty much summed up one of the primary reasons I'm currently spending a lot more time on FreeBSD than Linux. Over and above any technical or other merits, the development methodology of (specifically) the FreeBSD project is such that it is one of the easiest and most profitable open source projects to become personally involved in.
Re:The "contributions from unknown sources" proble (Score:1)
I was mainly responding to the AC(s?) who were making unwarranted assumptions about kernel developer's motivations. I used your case as the only example in evidence.
I agree with one of the other posts here, that even if you don't get a response, the fact that you've posted the issue to the right mailing list may help someone else, even before the patch is accepted. You could take this a step further, and set up a web page describing the issue in more detail for people who might not be in a position to fix the problem themselves. I know I have benefited from that kind of thing on a number of occasions.
Having read just two of the messages of yours that have been referred to here, I wonder if you couldn't have done a bit more digging by asking questions on the list like "Who is the maintainer of trap.c?" That's an easier question for people to deal with quickly, and might have led you down the right road. But maybe you did that.
Fork a new kernel... (Score:1)
Baz
Did you post to the new list? (Score:3)
Stir up some controversy! (Score:4)
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 [linuxcare.com]. 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 (Score:4)
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
They use the entities and goatse [goatse.cx] 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 [olsentwins.com] 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 [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
Quick and easy solution (Score:2)
Please reply to linus_torvalds@hotmail.com.
Your patch will immediately be entered into the kernel without a second thought.
love,
br4dh4x0r
If you find out please let us know. (Score:2)
I would like to submit several patches that I have created.
After that I would like to dump a load of suggestions and feature requests. I would also like to nag them about the direction they are taking with the kernal. I may also engage in a bit of hero worshipping followed by some light stalking.
Once I become bored with that, I expect I will want to be just friends and have each of them on my ICQ to chat with me all day. Eventually, I will sell my access to news media and spam lists. Either that or use mind control so that I can control them when they take over the universe.
Thank you.
Bugzilla? (Score:1)
LinuxNet IRC (Score:1)
Re: (Score:2)
Mailing lists. (Score:3)
Is it not about time for a more efficient way of organizing developers than the time honoured, but woefully inefficient mailing list? I know OSS people have a reputation for refusing to adopt new ways of working but this is insane.
We need something new and standard that is threaded, searchable and publicly accessable. Plain email just isn't an efficient medium for organizing tasks of this complexity and people's input and work get lost, or at the very least goes unrecognized.
Is there _any_ movement out there away from the primary use of mailing lists as an organizing medium?
Patience... (Score:5)
http://www.geocrawler.com/arch ives/3/35/2000/6/0/3875772/ [geocrawler.com]
This is from June, and the post indicates he posted the bugfix in December of 1999.
The "contributions from unknown sources" problem (Score:4)
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. (Score:4)
[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.
Re:This is very sad (Score:2)
Or better yet, set up a Slashcode based website, and moderate up the good patches. Unlike regular slashdot, there would be no Anonymous Cowards, and you could be banned for trolling.
Re:Getting the attention of developers (Score:2)
I DID NOT need to see That [goatse.cx]!
That is going to haunt me for the rest of my life, and may just make me impotent.
I think I am going blind.
Alan Cox Reads and Responds to his e-mail (Score:3)
I have also written Linus about porting to some new hardware my company was developing. Both times I got a full response in under three hours!
While these are just my stories I would find it hard to believe these guys are treating my e-mails as special. So if you have a question or bug fix, let them know. They may not be able to enter the code in write then but you should get a response pretty soon.
And read the linux-kernel mailing list FAQ. (Score:1)
As has been mentioned elsewhere, contacting the maintainer is first, best step. For the particular would-be patch which inspired this story, the maintainer's name and email address is now listed at the top of the source for /usr/src/linux/arch/i388/traps.c
in the 2.4.0-test7 kernel tree. This information was missing in the 2.2.x series tree.
We need a separate mailing list for patches ... (Score:2)
This would make a big difference. Even patches that are of the proper form are easy to miss among the hundreds of messages posted daily. The list is just too crazy.
The number of patches posted to the mailing list are significant, and most of them are very small, just a few lines. Since there are so many of them, and since they are quite distinct from the rest of the traffic on the list, they warrant their own mailing list.
Of course, the smart thing would be if everyone created a filter that separated messages with "[PATCH]" in the subject into their own folder, but who does that?
--
BSD Style (Score:1)
Re:The "contributions from unknown sources" proble (Score:2)
No, it means that because (a) significant time investment may be required and (b) kernel developers have many, many other emails and issues to deal with and (c) the original email, in this instance, didn't even identify who should look at it - because of all this, it really wasn't worth anyone's time unless they happened to have a particular interest in the bug in question.
> Noone ever bothered to acknowledge this guys effort. A simple "I looked, and you're a pinhead" would be enough. But all this guy got for his efforts was silence.
But even "I looked" takes time (did you read the original email, referenced elsewhere? I estimate a few hours work at least to really evaluate it properly.) There's a serious one-to-many effect at work here - few kernel developers, and many, many people with problems, agendas, and pet issues. And the reason there aren't a lot of kernel developers has nothing to do with the politics, and everything to do with who has the time and commitment to devote serious and ongoing effort to that kind of development.
> In my real job, when a peer spends this kind of time to identify a problem, I get spanked if I don't at least reply
You're making a lot of assumptions here. How does that peer communicate with you? Directly, or by dumping a message on a mailing list that he assumes you read? And if the item he's talking about doesn't fit the agenda for the project you're working to release, then your reply should be "sorry, can't work on that now." Which is the reply this issue might have gotten if the submitter had identified a person to submit it to.
> No wonder so many in the real world equate "Open Source" with "Childish Egomaniacs".
It seems to me that it takes a certain amount of self-centeredness to post a patch or bug report and then assume that you've been judged unkewl just because no-one answers. The issue you happen to have raised just may not be that interesting or important to anyone else. That's why I referred to "throwing a patch or bug report over the wall" - if you don't make any effort to actually find someone who might be interested, you shouldn't be offended when the person you haven't bothered to look for doesn't answer.
If you take silence from incredibly busy and dedicated people as a snub, then it's not them who are freezing you out, you're freezing yourself out. Step back and try to look at the situation objectively for a minute.
For the record, I have nothing to do with Linux development. I have worked as a lead developer on commercial projects with tens of thousands of users, though, so I have a bit of an idea what it's like to have hundreds of people all trying to get their own agendas realized.
it does work...eventually (Score:1)
Finally, I got a kernel that OOPS'ed repeatably on the bug. I e-mailed the scsi mailing list. I e-mailed the kernel channel. I e-mailed relevant authors in the maintainers list. Not a single reply.
Finally, in desperation, I e-mailed every single author who had ever stuck their name in scsi.c. After that, I got a reply, and had the bug fixed in about another 20 messages and a week or two.
Funny thing, they day after I had a stable bug fix, someone else e-mailed the scsi list with exactly the same problem...I happily mailed the patch to 'em. :) OSS does work IMHO.
Re: (Score:1)
Re:Stir up some controversy! (Score:1)
Or ask slashdot
Re:This is a common refrain. (Score:1)
Hey, if that happens, so much the better for OSS and *nix computing as a whole. I know I'm overabstracting here, but that's basically how this whole thing got started in the first place... imagine a kernel that is to Linux what Linux was to Minix.
Re:This is very sad (Score:1)
Re:Getting the attention of developers (Score:2)
That one's the favorite of these guys. It's rather unnerving, especially the tenth or twentieth time it pops up on you. If you read /. a lot you may want to append the line
127.0.0.1 goatse.cx
or maybe the IP address of a server you know and prefer, to your hosts file.
Yours WDK - WKiernan@concentric.net
How to attract attention. (Score:1)
(Otherwise you're dealing with a "random" maintainer, who is usually more responsive than Linus)
- Post on Linux-kernel. Ask people to test your
patch.
- wait a week
- post patch again, this time with "so-many people tested it. Please apply." CC Linus or Alan this time.
- Wait a week. Or at least 2 new (minor) releases. This prevents you from sending things twice when the maintainer happened to be "out of the office" for a moment.
- If it's still not included, send again.
Alan will usually respond with "this is bullshit" if it is, on the first try. Linus kind of assumes that you know that, and ignores you. Politely keep on asking for feedback. Send it again. And again (at the right pace: 2 releases or a week in between). He'll get annoyed at you, and finally tell you to shut up because your patch is bullshit. When he gets annoyed at having to throw your Email away every time, he'll give you feedback about what's wrong, and you'll be able to fix your patch.
So, if you hurry, you'll have feedback after about 3 weeks, and a "fixed" patch by week 4. It does take some "time" in that you have to keep coming back every week to see if your patch got accepted. One Email in december, one in june is "slow" enough to give the impression that you don't really care, and you might get ignored.
Also, Linus and Alan get soooo much Email that if they go away for a few days, they will have a hard time catching up, so are coping by just deleting everything that came in while they were away. If it was important, you're supposed to resend it.
Roger.
Send the patch to the maintainer (Score:1)
The *obvious* reply... (Score:1)
If it's important to you, if it's necessary to you, get the resources necessary to fix it. Self interest, itches, et al.
If you *absolutely* do not have the talent to fix it, do not have the resources, capability, or whatever, to fix the problem, and it needs to be fixed...
Submit and document the bug to unsavory webzine and list it under an article as a 'flaw' in Linux that makes it undeserving of the desktop/workstation/server market.
Or, write a program/virus/trojan to take advantage of the flaw ^^
I hope it's obvious that these were mainly joke replys!
The nick is a joke! Really!
Re:The *obvious* reply... (Score:1)
From what I understand, the original message said that he had submitted a patch, thus indicating he had fixed it himself.
how exactly do developers implement bug fixes? (Score:1)
The answer is simple... (Score:2)
That should get his attention, and from there the shit rolls down hill!
Implications (Score:1)
Don't get discouraged! (Score:5)
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.
This is a common refrain. (Score:2)
I've heard horror stories about people who have had to play 6-degrees of separation to get things into the right people. They have to find a friend who knows someone who met Alan Cox once, and hope to get each of their attention.
The fact that the linux kernel is so incredibly centralized isn't helping either. You want a patch in? It has to get to Linus. Which means you have to get to Alan/Maddog/etc. Which means you have to get to someone they know.
If there was a generalized system for hosting the kernel in CVS/Perforce/WebDAV/Whatever then things would be better. If there were people who would volunteer to first-screen-review any and all submissions things would help as well (envision patch@kernel.org going into a queue, and a volunteer who has "the ear" is able to review it and give first-cut comments on it, and possibly pass it up the chain to the next Saint in the hierarchy).
Ultimately, I hate to say this, but I see there being an eventual fork. Someone will take Linux, throw it up in CVS, allow checkins by quite a few people, and it's downhill from there. Maybe it'll be one of the distributors, maybe it'll be SGI (of the Gigantic Patch Library of Death), maybe it'll be IBM or even M$, or maybe it'll be some random college student who couldn't get the authors to listen. But it's pretty inevitable the way things are going.
If you're going to say the process is decentralized, then make it so! You don't have a reasonable engineering environment by having people spend twice as long trying to get someone to read their patch as they did writing it.
Reply to Alan's update (Score:2)
- Rejecting mail is not the same as disregarding. I don't think that the submitter meant to say that you "reject" it, but that you basically ignore it. whole different ball of wax there. I'm not saying you do or don't, but I think the the real issue is whether things that go to the main maintainers end up in a Big Black Hole.
- As previously pointed out, the author of said bug has both identified the bug and fixed it. It's not really a bug to be reported per se. There should be someplace to send patches, not just bug reports.
- The REPORTING-BUGS file part of 2.2.15 (what I'm currently running here, I checked) is way out date. It refers to mailing lists which don't exist, etc.
- Furthermore, it's clear that the author followed those instructions, and was still ignored. THAT'S the problem. He did what he was supposed to, and it's a big black hole.
- Finally, what happens if he contacts the maintainers (what happens if the maintainer is you?) and there's no response? Does his patch deserve to go into the abyss?
As much as I know that the people who maintain things are extremely overworked and underappreciated, there is a problem in that it's very difficult to get things into the kernel. Perhaps this needs to be discussed again.Re:Mailing list... (Score:1)
First off, he already stated that he was on the kernel mailing list and that's where he posted the bugfix. Second, while hanging around on the list, contributing, and eventually getting to know some people is a good idea if you plan to be doing lots of work on the kernel, it should NOT be necessary if all you want to do is submit a simple bugfix. That being said, I think the guy just needs to be patient. The kernel developers are swamped with things to do but eventually someone will probably get on it.
Never had any problems here... (Score:2)
Put micropayment to work! (Score:1)
Re:Mailing list... (Score:2)