information overload

Clayton Weaver (cgweav@eskimo.com)
Sun, 4 Oct 1998 03:02:59 -0700 (PDT)


In re: the discussion of kernel development strategies and patch
management

The most basic problem is information overload. The debate on code
repository tools is useful but not central to the problem, that's
a methodology implementation detail. Whether you have a good distributed
patch management software tool is just a difference in convenience for
actually putting patches into the tree and finding and testing aggregate
subsets of them after they are in there. A good tool would save some time,
but that's not the solution to the most basic problem, because all of the
information is still there and all of it goes through Linus. So that
debate should acquire an appropriate Subject: line in the header:

Source code repository management

I think we can agree that threading source code management discussions
under some obsolete Subject: line in the header is a bit non-productive.
People miss things they should read, assuming that the subject is politics
rather than tools.

The debate over heirarchical elite management vs ad hoc meritocracy may be
useful in understanding alternative strategies for project management, but
it is still not about the basic problem. The question isn't whether to
empower a core elite or not and who this would alienate and what the
political problems would be, the question is how to reduce the amount of
information that Linus has to personally digest. So that debate should
acquire a new Subject: line too:

horizontal vs heirarchical project management

What is needed is not necessarily delegation of "final say", ie building a
bureaucracy by delegating Linus's final ok on code inclusion, so the
bureaucratic elite objection is, imho, misplaced here. It's not about
responsibility and power. It's about filtering and formating information.

There are only three choices: the pace of development has to slow down, ie
patches get submitted to Linus less often; people accept that patch
submission is lossy, without complaining or criticizing Linus because in
aggregate they have overloaded his ability to respond in a timely fashion
to receiving patches; or a system is constructed to filter the information
that he has responsibility for approving.

The last alternative is equivalent to the suggestion to use the
MAINTAINERS file in the kernel source tree to find the appropriate person
to get first look at a proposed kernel patch (plus posting to the list or
posting a url for a patch available for testing, but that's orthogonal to
getting a patch integrated into the kernel tree).

So if Linus accepts volunteers to pre-filter patches in different areas of
the kernel source tree, that shouldn't be viewed as the incursion of a
power elite into the current horizontal development model. It's not about
power, it's not about status, it's about information bandwidth and
load-balancing.

And until a system like that is in place, complaining about the pace of
integrating this or that patch into Linus's kernel tree is not going
to be productive and just increases the useless noise level.

Regards, Clayton Weaver cgweav@eskimo.com (Seattle)

PS (off-topic but possibly useful to some readers notes on multi-byte
coding)

When you set down to write C code that functions as expected in
single-byte and multi-byte character locales, the three things you
want to know are:

* how single-byte size limits are affected by the locale change (usually
not at all, size limits normally stay in units of sizeof(char)
regardless of the encoding, but that needs to be spelled out somewhere);

* how the shell encodes things that it passes to the C runtime; the shell
isn't the filesystem, so what is it doing with argv[] and envp[], are
these strings utf or wchar_t;

* how is the C runtime affected, how does it represent internal strings
like __FUNCTION__, etc; the compiler reads utf-8 from the filesystem,
but is there anyplace where it doesn't leave strings in that encoding
until user code explicitly converts them to wchar_t.

It is most convenient for the coder if the runtime leaves everything in
utf-8 until the user's code explictly converts it to wchar_t when needed,
even if the compiler has to convert something to wchar_t itself for
conditional tests in multi-byte locales and then convert it back before
assigning it to the variable that the user sees. This way you never have
to ask yourself "what kind of character is the runtime or some
non-explicitly-wchar_t libc function passing me here", it's always going
to be utf-8 unless you generated or converted the string in your own code
(ignoring the issue of possible utf-7 read over the network for the
moment, since that's orthogonal to the question of what the runtime
and kernel deliver).

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