Lines Matching refs:it

23 explain some of the reasons why the community works like it does.
35 The kernel is written using GNU C and the GNU toolchain.  While it
36 adheres to the ISO C89 standard, it uses a number of extensions that are
42 and the extensions that it uses, and unfortunately there is no
75 new features are added to the kernel, it is recommended that new
78 userspace to change, it is recommended that you send the information or
97     rationale behind it. All new code is expected to follow the
100     review code if it is in the proper style.
108        - Who to send it to
111     will almost always prevent it.
139     it), as it resolves a lot of common misconceptions and confusion
154     apply it to the different development branches of the kernel.
199 tree, but need some help getting it in the proper form, the
204 Before making any actual modifications to the Linux kernel code, it is
206 purpose, nothing is better than reading through it directly (most tricky
239   - After two weeks a -rc1 kernel is released it is now possible to push
261 	"Nobody knows when a kernel will be released, because it's
280 two weeks, but it can be longer if there are no pressing problems.  A
311 Before a proposed patch is committed to such a subsystem tree, it is
316 revisions to it, and maintainers can mark patches as under review,
378 you want to bring up, before you post it to the list. A lot of things
400 to tune that by adding fancy mail-headers, people will not like it.
414 mail program fixed or change it until it works.
423 there is.  When you submit a patch for acceptance, it will be reviewed
448 the kernel.  Or at least be willing to prove your idea is worth it.
454 patch will not be accepted, and it is _not_ meant against you
456 resend it.
469     - "I tested it on 5 different architectures..."
474     - "We did it this way in AIX/ptx/Solaris, so therefore it must be
482     - "I rewrote all of the current mess, and here it is..."
498 order to get ideas across properly on mailing lists, so it is
507 dropped on it all at once.  The changes need to be properly introduced,
523    review for correctness (the time it takes is exponentially
526    Small patches also make it very easy to debug when something goes
527    wrong.  It's much easier to back out patches one by one than it is
528    to dissect a very large patch after it's been applied (and broken
549 unfinished work. Therefore it is good to get early in the process to
554 Also realize that it is not acceptable to send patches for inclusion
561 Along with breaking up your patches, it is very important for you to let
589 don't give up, it's possible. Many have done it before, and each had to