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/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:20 EST