linux-kernel - Re: [PATCH, RFC] A development process document

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 31 Jul 2008 13:22:17 +0100
From:	"Jochen Voß" <jochen.voss@...glemail.com>
To:	"Jonathan Corbet" <corbet@....net>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"Amanda McPherson" <amanda@...pherson.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>
Subject: Re: [PATCH, RFC] A development process document

Hi Jon,

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

2008/7/29 Jonathan Corbet <corbet@....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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/