[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: Linus
From: |
Stephen J. Turnbull |
Subject: |
[Gnu-arch-users] Re: Linus |
Date: |
Sat, 11 Oct 2003 00:33:47 +0900 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) |
>>>>> "Tom" == Tom Lord <address@hidden> writes:
> From: "Stephen J. Turnbull" <address@hidden>
> Yes. "Conceptual integrity ... dictates that the design must
> proceed from one mind, or from a very small number of agreeing
> resonant minds."
Tom> Who said that? Yes, I agree with the quote but it doesn't
Tom> answer my question (which was poorly phrased -- I see your
Tom> confusion).
Fred Brooks, _Mythical Man-Month_, "Aristocracy, Democracy, and System
Design".
Tom> I _am_ asking: "Do we really want Miles to have to repeat
Tom> sending a patch 3 times?"
No, we want Miles to use the system that Linus does, and it would no
longer be a problem, as Davide pointed out.
One of the not-small advantages of arch for kernel development is that
developers like Miles, Davide, and Andrea can use it (if Linus does).
It's the archive client that matters. Which is the point I ended my
last post with.
Also, your point that the identifiers "kernel", "Linus", and "Miles"
should be treated as variables is well-taken. But the kernel is a
familiar example at the upper end of the scale among projects that
people are familiar with. I think it will be hard to avoid using it
as the "canonical" example. We just need to keep in mind that there
are aspects of Linus's personality and the kernel codebase that will
not generalize at all to other projects and their managements.
>> Yes, even if available to everybody, that database is really
>> the tool of Linus and his lieutenants.
Tom> I'm not expecting to "let 10,000 kernel releases bloom". A
Tom> few 10 sounds about right, though, and from what I can tell,
Tom> is pretty close to what we actually have.
But as you point out, 100s is more like it. However, relations (by
which I mean common patch-sets connecting branches where those
changesets have been applied) are only going to dense near Linus's
branches, which takes you back to a small number of tens (Linus plus
the lieutenants).
> Second, the number of responses logged in your "artist's conception"
> web page was unrealistic, unless supported by the kind of automated
> testing I described, with really muscular organizations (like your
> sgi-skunkteam) running huge numbers of tests.
Tom> I'm not sure what you think is so unrealistic.
I think it unlikely that Miles (to take the example the thread starts
with) would get such flattering reports. At least from his
description, I gather that he has an active line of development with
substantial vitality, but of relatively specialized interest.
Tom> I didn't make explicit but did mean to imply that the three
Tom> requested patches aren't randomly selected from the set of
Tom> all available but were rather some that you'd reasonably
Tom> expect to show up in trees fairly quickly (note the comments
Tom> on them).
In other words, you're talking about something not so different from
the scenario of a debian-skonkteam coalition that I presented. Of
course my example was carefully spun to imply that it would only get
attention because it was from developers with "Personal Access" to
Linus. But if you take that out, you're still left with the question
of whether the amount of interest as measured by # of comments and #
of well-known development lines with those patches applied can be
uncorrelated with being "close to Linus" in some metric.
To sum up, I think that the patch queue database will reflect current
reality more than it can help shape future reality.
Tom> I think you're taking too narrow a view of what's going on
Tom> the kernel world when you focus on just a few big names.
I'm not focusing on the few big names a priori. I'm arguing that the
physical realities of communication, even with the nice tools you
propose (not to mention have already written :-), combined with the
essentially aristocratic nature of design, will lead to such focus.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
- [Gnu-arch-users] Re: taglines vs explicit, (continued)
- [Gnu-arch-users] Re: taglines vs explicit, Miles Bader, 2003/10/07
- [Gnu-arch-users] Re: taglines vs explicit, Stephen J. Turnbull, 2003/10/07
- [Gnu-arch-users] Re: taglines vs explicit, Miles Bader, 2003/10/08
- [Gnu-arch-users] Re: taglines vs explicit, Stephen J. Turnbull, 2003/10/09
- [Gnu-arch-users] Linus, Tom Lord, 2003/10/09
- Re: [Gnu-arch-users] Linus, Davide Libenzi, 2003/10/09
- [Gnu-arch-users] Re: Linus, Miles Bader, 2003/10/09
- [Gnu-arch-users] Re: Linus, Miles Bader, 2003/10/09
- [Gnu-arch-users] Re: Linus, Stephen J. Turnbull, 2003/10/10
- [Gnu-arch-users] Re: Linus, Tom Lord, 2003/10/10
- [Gnu-arch-users] Re: Linus,
Stephen J. Turnbull <=
- [Gnu-arch-users] Re: Linus, Tom Lord, 2003/10/10
- [Gnu-arch-users] Re: Linus, Stephen J. Turnbull, 2003/10/12
- [Gnu-arch-users] Re: Linus, Tom Lord, 2003/10/12
- [Gnu-arch-users] Re: Linus, Stephen J. Turnbull, 2003/10/14
- [Gnu-arch-users] patch trackers (was the thread that shall be unnamed), Tom Lord, 2003/10/14
- [Gnu-arch-users] Re: patch trackers, Stephen J. Turnbull, 2003/10/15
- Re: [Gnu-arch-users] Re: Linus, Zack Brown, 2003/10/10
- Re: [Gnu-arch-users] Re: Linus, Ollivier Robert, 2003/10/11
- [Gnu-arch-users] Re: Linus, Miles Bader, 2003/10/11
- Re: [Gnu-arch-users] Re: Linus, Zack Brown, 2003/10/11