[Gnu-arch-users] Re: Linus

[Stephen J. Turnbull]

>>>>> "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.