On 08/17/14 11:30, Markus Osterhoff wrote: > ... being > - HOWTO > - ManagementStyle > - SecurityBugs > - SubmittingpAtches > > Signed-off-by: Markus Osterhoff <linux-kernel@xxxxxxxxxx> > --- > Documentation/HOWTO | 22 +++++++++++----------- > Documentation/ManagementStyle | 16 ++++++++-------- > Documentation/SecurityBugs | 2 +- > Documentation/SubmittingPatches | 4 ++-- > 4 files changed, 22 insertions(+), 22 deletions(-) > > diff --git a/Documentation/HOWTO b/Documentation/HOWTO > index 57cf5ef..7b6a938 100644 > --- a/Documentation/HOWTO > +++ b/Documentation/HOWTO > @@ -41,7 +41,7 @@ divisions and floating point are not allowed. It can sometimes be > difficult to understand the assumptions the kernel has on the toolchain > and the extensions that it uses, and unfortunately there is no > definitive reference for them. Please check the gcc info pages (`info > -gcc`) for some information on them. > +gcc') for some information on them. Backquotes imply that the contents (string) can be entered at a shell prompt; i.e., they are a command. > > Please remember that you are trying to learn how to work with the > existing development community. It is a diverse group of people, with > @@ -105,7 +105,7 @@ required reading: > and send a patch, including (but not limited to): > - Email contents > - Email format > - - Who to send it to > + - Whom to send it to Either. Yes, I know that the latter is historically correct, but either way is now accepted AFAIK (according to press reports; I haven't looked it up). > Following these rules will not guarantee success (as all patches are > subject to scrutiny for content and style), but not following them > will almost always prevent it. > @@ -234,9 +234,9 @@ process is as follows: > Linus, usually the patches that have already been included in the > -next kernel for a few weeks. The preferred way to submit big changes > is using git (the kernel's source management tool, more information > - can be found at http://git-scm.com/) but plain patches are also just > + can be found at http://git-scm.com/), but plain patches are also just > fine. > - - After two weeks a -rc1 kernel is released it is now possible to push > + - After two weeks an -rc1 kernel is released; it is now possible to push > only patches that do not include new features that could affect the > stability of the whole kernel. Please note that a whole new driver > (or filesystem) might be accepted after -rc1 because there is no > @@ -248,15 +248,15 @@ process is as follows: > - A new -rc is released whenever Linus deems the current git tree to > be in a reasonably sane state adequate for testing. The goal is to > release a new -rc kernel every week. > - - Process continues until the kernel is considered "ready", the > + - This process continues until the kernel is considered "ready", the > process should last around 6 weeks. > - Known regressions in each release are periodically posted to the > linux-kernel mailing list. The goal is to reduce the length of > that list to zero before declaring the kernel to be "ready," but, in > - the real world, a small number of regressions often remain at > + the real world, a small number of regressions often remains at > release time. > > -It is worth mentioning what Andrew Morton wrote on the linux-kernel > +It is worth mentioning what Andrew Morton wrote on the Linux-kernel The mailing list is "linux-kernel". > mailing list about kernel releases: > "Nobody knows when a kernel will be released, because it's > released according to perceived bug status, not according to a > @@ -293,10 +293,10 @@ daily and represent the current state of Linus' tree. They are more > experimental than -rc kernels since they are generated automatically > without even a cursory glance to see if they are sane. > > -Subsystem Specific kernel trees and patches > +Subsystem specific kernel trees and patches > ------------------------------------------- > -The maintainers of the various kernel subsystems --- and also many > -kernel subsystem developers --- expose their current state of > +The maintainers of the various kernel subsystems -- and also many > +kernel subsystem developers -- expose their current state of > development in source repositories. That way, others can see what is > happening in the different areas of the kernel. In areas where > development is rapid, a developer may be asked to base his submissions > @@ -355,7 +355,7 @@ your skills, and other developers will be aware of your presence. Fixing > bugs is one of the best ways to get merits among other developers, because > not many people like wasting time fixing other people's bugs. > > -To work in the already reported bug reports, go to http://bugzilla.kernel.org. > +To work on the already reported bug reports, go to http://bugzilla.kernel.org. > If you want to be advised of the future bug reports, you can subscribe to the > bugme-new mailing list (only new bug reports are mailed here) or to the > bugme-janitor mailing list (every change in the bugzilla is mailed here) > diff --git a/Documentation/ManagementStyle b/Documentation/ManagementStyle > index a211ee8..b68f726 100644 > --- a/Documentation/ManagementStyle > +++ b/Documentation/ManagementStyle > @@ -2,7 +2,7 @@ > Linux kernel management style > > This is a short document describing the preferred (or made up, depending > -on who you ask) management style for the linux kernel. It's meant to > +on who you ask) management style for the Linux kernel. It's meant to > mirror the CodingStyle document to some degree, and mainly written to > avoid answering (*) the same (or similar) questions over and over again. > > @@ -11,7 +11,7 @@ simple coding style rules, so this document may or may not have anything > to do with reality. It started as a lark, but that doesn't mean that it > might not actually be true. You'll have to decide for yourself. > > -Btw, when talking about "kernel manager", it's all about the technical > +Btw., when talking about "kernel manager", it's all about the technical BTW (or Btw) is common -- no period. > lead persons, not the people who do traditional management inside > companies. If you sign purchase orders or you have any clue about the > budget of your group, you're almost certainly not a kernel manager. > @@ -37,11 +37,11 @@ actually true. > The name of the game is to _avoid_ having to make a decision. In > particular, if somebody tells you "choose (a) or (b), we really need you > to decide on this", you're in trouble as a manager. The people you > -manage had better know the details better than you, so if they come to > +manage had better known the details better than you, so if they come to nope. > you for a technical decision, you're screwed. You're clearly not > competent to make that decision for them. > > -(Corollary:if the people you manage don't know the details better than > +(Corollary: if the people you manage don't know the details better than > you, you're also screwed, although for a totally different reason. > Namely that you are in the wrong job, and that _they_ should be managing > your brilliance instead). > @@ -80,10 +80,10 @@ easily undone. > > It turns out that some people have trouble with this approach, for two > reasons: > - - admitting you were an idiot is harder than it looks. We all like to > + - Admitting you were an idiot is harder than it looks. We all like to > maintain appearances, and coming out in public to say that you were > wrong is sometimes very hard indeed. > - - having somebody tell you that what you worked on for the last year > + - Having somebody tell you that what you worked on for the last year > wasn't worthwhile after all can be hard on the poor lowly engineers > too, and while the actual _work_ was easy enough to undo by just > deleting it, you may have irrevocably lost the trust of that > @@ -109,12 +109,12 @@ sure as hell shouldn't encourage them by promising them that what they > work on will be included. Make them at least think twice before they > embark on a big endeavor. > > -Remember: they'd better know more about the details than you do, and > +Remember: they'd better known more about the details than you do, and nope. > they usually already think they have the answer to everything. The best > thing you can do as a manager is not to instill confidence, but rather a > healthy dose of critical thinking on what they do. > > -Btw, another way to avoid a decision is to plaintively just whine "can't > +Btw., another way to avoid a decision is to plaintively just whine "can't Btw is OK. > we just do both?" and look pitiful. Trust me, it works. If it's not > clear which approach is better, they'll eventually figure it out. The > answer may end up being that both teams get so frustrated by the > diff --git a/Documentation/SecurityBugs b/Documentation/SecurityBugs > index a660d49..5c8e0eb 100644 > --- a/Documentation/SecurityBugs > +++ b/Documentation/SecurityBugs > @@ -7,7 +7,7 @@ Linux kernel security team. > > The Linux kernel security team can be contacted by email at > <security@xxxxxxxxxx>. This is a private list of security officers > -who will help verify the bug report and develop and release a fix. > +who will help to verify the bug report and develop and release a fix. > It is possible that the security team will bring in extra help from > area maintainers to understand and fix the security vulnerability. > > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches > index 0a523c9..a358031 100644 > --- a/Documentation/SubmittingPatches > +++ b/Documentation/SubmittingPatches > @@ -227,8 +227,8 @@ Linux kernel. His e-mail address is <torvalds@xxxxxxxxxxxxxxxxxxxx>. > He gets a lot of e-mail, so typically you should do your best to -avoid- > sending him e-mail. > > -Patches which are bug fixes, are "obvious" changes, or similarly > -require little discussion should be sent or CC'd to Linus. Patches > +Patches, which are bug fixes, are "obvious" changes, or similarly Patches which are bug fixes or "obvious" changes or similarly > +require little discussion, should be sent or CC'd to Linus. Patches why the added comma? > which require discussion or do not have a clear advantage should > usually be sent first to linux-kernel. Only after the patch is > discussed should the patch then be submitted to Linus. > -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
