Messages in this thread | | | Date | Tue, 19 Sep 2000 13:24:07 +0100 (BST) | From | Riley Williams <> | Subject | Re: kernel governance |
| |
Hi Tony.
> sorry for the cold call - i've been trying to find a statement > about 'kernel governance' and how new code is accepted into the > kernel...
To help anybody else wondering about these issues, I've cc'd my reply to the Linux-Kernel mailing list for comments. However, please note that the comments herein are expressions of my own opinions, and may not reflect those of other developers.
Additional comments from other developers should be cc'd to Tony as I don't think he's on this list. However, I am on the list, so there is no need to CC to me...
> any hints?
Well, I'm not even sure what you mean by "kernel governance" but the way to get your code into the kernel is well documented. Here's a basic summary of the procedure:
1. Subscribe to the Linux-Kernel mailing list. This is where ALL issues relating to the ENTIRE Linux kernel are thrown open for discussion.
I will warn you in advance that this is a VERY active list and it is not unusual to get 300+ emails a day in that one list. My personal record from the Linux-Kernel list alone is 793 emails in one day. Make sure you can handle emails in that sort of volume first.
2. Monitor the list for AT LEAST 15 DAYS to see what issues are being discussed at the moment. In particular, watch out for ANY emails from "Linus Torvalds" or "Alan Cox" which mention such things as "Feature Freeze".
3. When you are satisfied with your understanding of the dynamics of the Linux-Kernel mailing list, post an email (sent using "Plain Text" mode - HTML emails are IGNORED by MANY of the kernel developers simply because of the volume of mail on the list.
This email should contain a description of the purpose of your code, and should have attached to it (in MIME format) a PATCH against the relevant CURRENT kernel source tree that is in UNIFIED DIFF FORMAT. This format is generated by applying the -u4 parameter to the diff command.
Note that the patch should NOT be embedded in the text of the email as doing so will almost certainly make the patch useless - it will either get munged by your email sending software or by the recipients mail reading software.
Either the subject line or the descriptive text MUST state which kernel the patch file was generated against, and the email MUST have a subject line, preferably with the word PATCH in upper case together with a short (less than 40 character) description of what issue the patch deals with.
Note that the current kernels can normally be determined by pointing your web browser to http://www.kernel.org and scrolling down to the bottom of the page.
4. Watch out for comments on your patch, and DEAL WITH THEM. Some people just ignore any comments, apparently on the assumption that they know what the kernel needs better than those who have been working on it far longer than they have, and after a while, the developers just stop reading their emails.
You will also receive comments from people who have either just plain misunderstood your post, or who operate on the basis that their code is sacrosanct and your patch against it isn't worth considering as a result. Again, you will have to find a way of dealing with them.
One basic rule here though: NEVER FLAME ANYBODY - NOT EVEN IN RESPONSE TO A FLAME. You'll only get yourself a bad name and reputation by doing so.
The following are common reasons for patches posted to the Linux Kernel Developers mailing list being rejected:
a. The patch is too complex.
A patch that deals with too many issues will be rejected simply because of its size, as those who are responsible for the relevant part(s) of the kernel just don't have time to go through them.
If you have dealt with several issues and the patches for each issue do not overlap, send the relevant patch for each issue in a separate email dealing just with that issue.
If you have dealt with several issues and the patches overlap, you basically have two choices:
1. If the patch dealing just with the issues that overlap is not too large (say less than 50 lines in length), send a combined patch dealing just with the issues that overlap, and enumerate precicely which issues are dealt with, emphasising that they overlap.
2. If the patch is too large, decide which of the issues is "most important" and send a patch dealing just with that issue. Wait to see what happens to that patch, then send a patch against the result dealing with the next most important issue.
Note that in this context, where there are three or more patches overlapping, the "most important" patch is often the one that has the result of de-overlapping most of the other patches.
Note that "patches overlap" in the above means that lines relating to two different issues appear in the same patch hunk.
b. The patch treats the symptoms, not the bug
A patch that just treats the symptoms of a bug without fixing the bug itself will most often be rejected without comment.
c. The patch is not SMP safe.
Watch out for this one - the Linux kernel source tree needs to compile successfully for both UP (UniProcessor) and SMP (Synchronous MultiProcessor) environments, with the same code working in both.
However, if this is the reason for rejection, you will normally be told precicely why your patch is not SMP safe.
d. An equivalent patch from somebody else has already been applied.
It happens {Shrug}.
e. The patch doesn't apply cleanly against the stated kernel, or against the current kernel if that is different from the one you generated it against.
If the current kernel changed around the time you generated the patch (which happens) and there were major changes to the file you patched (which also happens), you will need to generate a new patch taking account of the changes and resubmit it.
There are of course other reasons for rejection, but those occur so often as to deserve quoting in advance.
Best wishes from Riley.
--- * Despite all the medical advances of the 20th century, * the mortality rate remains unchanged at 1 death per * person.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |