gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] Linus


From: Tom Lord
Subject: [Gnu-arch-users] Linus
Date: Thu, 9 Oct 2003 12:46:21 -0700 (PDT)


    > From: "Stephen J. Turnbull" <address@hidden>

    > >>>>> "Miles" == Miles Bader <address@hidden> writes:

    >     Miles> and they usually _do_ get applied without comment after I
    >     Miles> resend them 3-4 times.

    > Ah!  Now I see where you're coming from.

    > I'm not sure where you're going, though.  I still think that what
    > Linus (and Tom) do requires a skillful human with a spark (or six) of
    > genuis reading the submissions.  Anything the system can do to make
    > patch application a one-click affair will help, but even a full-scale
    > intelligent patch queue manager that

    > 1.  automatically applies the patch, and just as automatically rejects
    >     it if it doesn't apply
    > 2.  automatically builds, and just as automatically rejects it if the
    >     build fails
    > 3.  automatically runs the regression test suite, and just as
    >     automatically rejects if any test fails
    > 4.  provides any relevant human-understandable form (eg, a manpage or
    >     info file should be compiled and presented in an appropriate viewer)

    > would provide only a factor of 2 speed up, don't you think

"factor of 2" for whom?   Let me try to paint a picture.

The first thing missing here, and this seems to be true of BK, arch,
svn, and everything else, is an actual patch queue.

Why should Miles need to resend an identical patch more than once?
That's absurd.

Why isn't it the case that he sends it once, and then if he wants to
know it's status, he looks at some web page?  Are Linus' limits on his
ability to process email _really_ supposed to be a bottleneck on linux
kernel development?

We crudely use the Savannah bug tracker for this purpose in the arch
project, but it could certainly be far better.

All that "automatically applies, tests, etc." foo seems to me like an
extension of something very, very basic that's missing -- and that's
an actual database of received patches and their status.

Let's suppose that we have such a database.   What becomes of Linus?
The question hinges, to a certain extent, on "whose database is it?".   

One idea is that it's Linus' database.   It's his queue.   A patch is
"applied" or "rejected" or "pending" depending on what Linus does.

A different idea is that it's a shared database.   It's everybody's
queue where we're all equal.   For example, can I query the database
this way:

     Mere human:

        Oh, great patch-queue database, please tell me: what is the
        status of a linus-2.6-stable tree with patches #4598, #987234, and
        #32454 applied?

     Great machine:

        There is no tree matching that criterea precisely. 
        [create locally]

        There are 125 comments on this set of patches, including
        9 from those in your watch-list.  [view]

        Approximate trees matching your search
                                sort by: *prefs* [date] [other]

        * [linux--linus-devo--2.6]

          The head of `linux--linus-devo--2.6' has [#4598] and [#32454]
          applied.   It is missing [#987234].  That tree has received
          confidence votes: 

                 * linus-sniff-test:            B-      [view]
                 * osdl-nightly-test:           A       [view]
                 * osdl-comprehensive-series-a: A       [view]
                 * osdl-comprehensive-series-b: C+      [view]
                 * suse-stress-test:            C-      [view]

          The head revision of this development line has an additional
          42 first-tier patches applied [view list].

          This development line has a user karma rating of 3.2/5
          (8,137,345 reporting).

          Your karma-filter `major-vendors' assigns this development
          line a karma rating of 4/5 (7 reporting). [view]


        * [linux--sgi-skunkteam-devo--2.6]

          The head of `linux--sgi-skunkteam-devo--2.6' has all
          of those changes applied.   That tree has received
          confidence votes:

                 * osdl-nightly-test:           A       [view]
                 * sgi-skunks-acceptance:       A-      [view]
                 * sgi-hard-tests:              A-      [view]

          The head revision of this development line has an additional
          12 first-tier patches applies [view list].

          This development line has a user karma rating of 4.2/5
          (645 reporting).

          Your karma-filter `major-vendors' assigns this development
          line a karma rating of 5/5 (3 reporting). [view]


        * [linux--debian-unstable--2.6]

          The head of `linux--debian-unstable--2.6' has all
          of those changes applied.   That tree has received
          confidence votes:

                [.....]

          Your karma-filter `major-vendors' assigns this development
          line a karma rating of 4/5 (1 reporting). [view]

                                                *1* [2] [3]


Let's go that-a-way.   Software is politics and yadda yadda yadda.

-t




reply via email to

[Prev in Thread] Current Thread [Next in Thread]