lkml.org 
[lkml]   [2002]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A modest proposal -- We need a patch penguin
On Fri, 22 Feb 2002, Hans Reiser wrote:

| We need to move from discussing whether Linus can scale to whether the
| Linux Community can scale.

I have to agree with much of what Hans has written here.

and one of the biggest things that would help in this regard, IMHO,
is to (dare I say "require") provide documentation for kernel
API changes or semantics. "Read the source" or "Use the source"
doesn't scale well either, when 10K kernel developers are
trying to use a new widget in 2.5.4, but they all ask questions
on lkml about how it's done.

Let's keep Documentation/* stuff up to date. Whether it's in
text or DocBook format doesn't matter much.
Or have web pages for it if that's preferred by the project or
individual(s).

~Randy

| Every organization needs to have clearly defined algorithms for
| determining what work is done by who. For the linux community, our work
| consists in part of reviewing patches. Incoherent inconsistent
| delegation is the only reason why we are having scaling problems. We
| have a consistent recurring problem (yes, I know, a few lucky folks like
| me don't have this problem, but it is clear to see that WE as a
| community have this problem).
|
| It is important that there be a consistent feeling among patch
| submitters that they know where to send their patches for
| acceptance/rejection. There should be NO patches which go out, and not
| even a rejection comes back.
|
| Every organization has clearly defined procedures for allocating the
| flow of work. It is called a management structure. That is what we
| need, and we need a formal well defined and externally visible one. An
| informal undefined network of friends is just not suitable for an
| organization where the flow of email is as large as it is in the Linux
| Community.
|
| Linus, I would like you to stop saying that you cannot scale to where
| you can read every email, and start determining what it takes to make
| the Linux Community infrastructure underneath you responsive to patches.
| Bitkeeper is a great start, but you also need to create a management
| structure and interface that is clearly defined to the external
| community. Saying that the maintainers list is ignored by you means
| that you need to create something that is not ignored by you. You also
| need to create a system (bitkeeper can perhaps help, Larry?) for
| tracking who fails to respond to patches, and (after a few warnings)
| remove them as maintainers.
|
| Our problems are not novel. Let us apply standard business school
| methodologies to them.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.251 / U:10.508 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site