[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m3wsj1ipo4.fsf@lwn.net>
Date: Thu, 31 Jul 2008 17:45:15 -0600
From: Jake Edge <jake@....net>
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,
A few minor things I found:
Jonathan Corbet <corbet@....net> writes:
> +in existence. Since its humble beginning in 1991, this kernel has evolved
> +into a best-of-breed operating system component which runs on pocket-sized
> +digital music players, desktop PCs, the largest supercomputers in
> +existence, and all types of system in between. It is a robust, efficient,
systems
> +- Binary modules greatly increase the difficulty of debugging kernel
> + problems, to the point that most kernel developers will not even try. So
> + the distribution of binary-only modules will make support harder for
> + those who use them.
The last sentence reads a little funny to me, maybe something like:
By distributing binary-only modules, you make it harder for you and your
users to get support.
> +kernel under the GPL. Code which has not been licensed as free software by
> +its owner, or which risks creating copyright-related problems for the
> +kernel (such as code which derives from improper reverse-engineering
> +efforts) cannot be contributed.
To me, this sort of implies that all reverse-engineering is improper, which
is not what you meant to say, I don't think.
> +A relatively straightforward discipline is followed with regard to the
> +merging of patches for each release. At the beginning of each development
> +cycle, the "merge window" is said to be open. At this time, code which is
"At this time" sounds like you are saying "now", "At that time" perhaps?
(maybe too picky)
> + - Early review. Patches are posted to the relevant mailing list, and
> + developers on that list reply with any comments they may have. This
> + process should turn up any major problems with a patch, if all goes
> + well.
The comma after "patch" seems confusing.
> +When the merge window opens, top-level maintainers will ask Linus to "pull"
> +the patches they have selected for merging from their repositories. If
> +Linus agrees, the stream of patches will flow up into his repository,
> +becoming part of the mainline kernel. The amount of attention that Linus
> +pays to specific patches received in a pull operation varies. It is clear
> +that, sometimes, he looks quite closely. But, as a general, Linus trusts
> +the subsystem maintainers to not send bad patches upstream.
do you mean that Linus is a general? or should that be "general rule"? It
could work either way.
> +degree of politeness. But there is no other place where the kernel
> +development community comes together as a whole; developers will avoid this
> +list at the risk of missing important information.
the last clause sounds like developers *will* avoid the list, maybe:
developers who avoid this list risk missing important information
> +patches. Those are the people who be best placed to help with a new
> +development project.
"who be best placed"? who will be best placed ...
> +One of the heavier debugging tools is the locking checker, or "lockdep."
should lockdep have a period?
> +how many people will build your code into their kernels. And, of course,
> +where there's testers, there's bug reports.
where there are testers, there are bug reports.
> +development history. An inconvenient patch (one which breaks bisection,
> +say, or which has some other sort of obvious bug) can be fixed in place or
> +make to disappear from the history entirely. A patch series can be
be made to disappear
> +read. Many internal kernel APIs are documented using the kerneldoc
> +mechanism; "make htmldocs" or "make pdfdocs" can be used to generate those
> +documents in HTML or PDF format (though the version of TeX shipped by some
> +distributions run into internal limits and fails to process the documents
> +properly).
"run into internal limits"? but, "runs into internal limits" doesn't seem
quite right either.
hope that helps,
jake
--
Jake Edge - jake@....net - http://lwn.net
--
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/
Powered by blists - more mailing lists