Re: [PATCH, RFC] A development process document

["Jochen Voß" <jochen.voss@googlemail.com>]

Hi Jon,

Some more minor issues (disclaimer: I am not a native speaker of English).

2008/7/29 Jonathan Corbet <corbet@lwn.net>:
> +One of the most compelling features of Linux is that it is accessible to
> +these developers; anybody with the requisite skills can improve Linux and
> +influence the direction of its development.  Proprietary products cannot
> +offer this kind of openness, which is a characteristic of the free software
> +process.  But, if anything, the kernel is open even than most other free
> +software projects. ...

This last sentence looks strange to me.  Maybe a "more" is missing somehow?
[ I sent this one before, but forgot the proper Cc:s.  Sorry about that. ]

> +Years of experience with the kernel development community has taught a
> +clear lesson: ...
"have taught"?

> +5.5: SENDING THE PATCH
Maybe somewhere in this section say something about avoiding HTML
email and attachments?

> + - Signed-off-by: this is a developer's certification that he or she has
> +   the right to submit the patch for inclusion into the kernel.  It is an
> +   agreement to the Developer's Certificate of Origin, the full text of
> +   which can be found in SubmittingPatches.  Code without a proper signoff
> +   cannot be merged into the mainline.
Earlier you prefixed file names with "Documentation/".  Maybe do the
same here (and in the following paragraphs) for consistency?

> + - If you are responding to a bug report or a feature request, copy those
> +   people as well.
Maybe "the reporters" or similar instead of "those people"?

> +6.1: WORKING WITH REVIEWERS
> +
> +A patch of any significance will result in a number of comments from other
> +developers as they review the code.  Working with reviewers can be, for
> +many developers, the most indimidating part of the kernel development
"intimidating"

> +Excessive use of this capability can lead to other problems, though, beyond
> +a simple obsession for the creation of the perfect project history.
> +Rewriting history will rewrite the changes contained in that history,
> +turning a tested (hopefully) kernel tree into an untested one.  But, beyond
> +that, developers cannot easily collaborate if they do not have a shared
> +view of the project history; if you rewrite history which other developers
> +have pulled into their repositories, you will make life much more difficult
> +for those developers going forward. ...
Is the "going forward" meant to be there?

I hope this helps,
Jochen
-- 
http://seehuhn.de/