Commit ad86de80 authored by Randy Dunlap's avatar Randy Dunlap Committed by David S. Miller

Documentation/networking: netdev-FAQ typo corrections

Various typo fixes to netdev-FAQ.txt:
- capitalize Linux
- hyphenate dual-word adjectives
- minor punctuation fixes
Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 2f715c1d
...@@ -4,23 +4,23 @@ Information you need to know about netdev ...@@ -4,23 +4,23 @@ Information you need to know about netdev
Q: What is netdev? Q: What is netdev?
A: It is a mailing list for all network related linux stuff. This includes A: It is a mailing list for all network-related Linux stuff. This includes
anything found under net/ (i.e. core code like IPv6) and drivers/net anything found under net/ (i.e. core code like IPv6) and drivers/net
(i.e. hardware specific drivers) in the linux source tree. (i.e. hardware specific drivers) in the Linux source tree.
Note that some subsystems (e.g. wireless drivers) which have a high volume Note that some subsystems (e.g. wireless drivers) which have a high volume
of traffic have their own specific mailing lists. of traffic have their own specific mailing lists.
The netdev list is managed (like many other linux mailing lists) through The netdev list is managed (like many other Linux mailing lists) through
VGER ( http://vger.kernel.org/ ) and archives can be found below: VGER ( http://vger.kernel.org/ ) and archives can be found below:
http://marc.info/?l=linux-netdev http://marc.info/?l=linux-netdev
http://www.spinics.net/lists/netdev/ http://www.spinics.net/lists/netdev/
Aside from subsystems like that mentioned above, all network related linux Aside from subsystems like that mentioned above, all network-related Linux
development (i.e. RFC, review, comments, etc) takes place on netdev. development (i.e. RFC, review, comments, etc.) takes place on netdev.
Q: How do the changes posted to netdev make their way into linux? Q: How do the changes posted to netdev make their way into Linux?
A: There are always two trees (git repositories) in play. Both are driven A: There are always two trees (git repositories) in play. Both are driven
by David Miller, the main network maintainer. There is the "net" tree, by David Miller, the main network maintainer. There is the "net" tree,
...@@ -35,7 +35,7 @@ A: There are always two trees (git repositories) in play. Both are driven ...@@ -35,7 +35,7 @@ A: There are always two trees (git repositories) in play. Both are driven
Q: How often do changes from these trees make it to the mainline Linus tree? Q: How often do changes from these trees make it to the mainline Linus tree?
A: To understand this, you need to know a bit of background information A: To understand this, you need to know a bit of background information
on the cadence of linux development. Each new release starts off with on the cadence of Linux development. Each new release starts off with
a two week "merge window" where the main maintainers feed their new a two week "merge window" where the main maintainers feed their new
stuff to Linus for merging into the mainline tree. After the two weeks, stuff to Linus for merging into the mainline tree. After the two weeks,
the merge window is closed, and it is called/tagged "-rc1". No new the merge window is closed, and it is called/tagged "-rc1". No new
...@@ -46,7 +46,7 @@ A: To understand this, you need to know a bit of background information ...@@ -46,7 +46,7 @@ A: To understand this, you need to know a bit of background information
things are in a state of churn), and a week after the last vX.Y-rcN things are in a state of churn), and a week after the last vX.Y-rcN
was done, the official "vX.Y" is released. was done, the official "vX.Y" is released.
Relating that to netdev: At the beginning of the 2 week merge window, Relating that to netdev: At the beginning of the 2-week merge window,
the net-next tree will be closed - no new changes/features. The the net-next tree will be closed - no new changes/features. The
accumulated new content of the past ~10 weeks will be passed onto accumulated new content of the past ~10 weeks will be passed onto
mainline/Linus via a pull request for vX.Y -- at the same time, mainline/Linus via a pull request for vX.Y -- at the same time,
...@@ -59,12 +59,12 @@ A: To understand this, you need to know a bit of background information ...@@ -59,12 +59,12 @@ A: To understand this, you need to know a bit of background information
IMPORTANT: Do not send new net-next content to netdev during the IMPORTANT: Do not send new net-next content to netdev during the
period during which net-next tree is closed. period during which net-next tree is closed.
Shortly after the two weeks have passed, (and vX.Y-rc1 is released) the Shortly after the two weeks have passed (and vX.Y-rc1 is released), the
tree for net-next reopens to collect content for the next (vX.Y+1) release. tree for net-next reopens to collect content for the next (vX.Y+1) release.
If you aren't subscribed to netdev and/or are simply unsure if net-next If you aren't subscribed to netdev and/or are simply unsure if net-next
has re-opened yet, simply check the net-next git repository link above for has re-opened yet, simply check the net-next git repository link above for
any new networking related commits. any new networking-related commits.
The "net" tree continues to collect fixes for the vX.Y content, and The "net" tree continues to collect fixes for the vX.Y content, and
is fed back to Linus at regular (~weekly) intervals. Meaning that the is fed back to Linus at regular (~weekly) intervals. Meaning that the
...@@ -217,7 +217,7 @@ A: Attention to detail. Re-read your own work as if you were the ...@@ -217,7 +217,7 @@ A: Attention to detail. Re-read your own work as if you were the
to why it happens, and then if necessary, explain why the fix proposed to why it happens, and then if necessary, explain why the fix proposed
is the best way to get things done. Don't mangle whitespace, and as is the best way to get things done. Don't mangle whitespace, and as
is common, don't mis-indent function arguments that span multiple lines. is common, don't mis-indent function arguments that span multiple lines.
If it is your 1st patch, mail it to yourself so you can test apply If it is your first patch, mail it to yourself so you can test apply
it to an unpatched tree to confirm infrastructure didn't mangle it. it to an unpatched tree to confirm infrastructure didn't mangle it.
Finally, go back and read Documentation/SubmittingPatches to be Finally, go back and read Documentation/SubmittingPatches to be
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment