Re: Patch Acceptance Procedure

From: jmjonesat_private
Date: Mon Jul 23 2001 - 17:29:21 PDT

  • Next message: Seth Arnold: "Re: Patch Acceptance Procedure"

    Excellent points, btw... most convincing.
    
    On Mon, 23 Jul 2001, Seth Arnold wrote:
    
    > On Mon, Jul 23, 2001 at 08:02:53PM -0400, jmjonesat_private wrote:
    
    > > It shifts the burden of "proof of necessity", which I *thought* was
    > > "necessary in" instead of "in until necessary out".
    > 
    > Aye; but further changes may render pieces unnecessary, redundant, etc.
    > Or someone may propose a different method that is faster/smaller/more
    > elegant. The end result still needs to be "necessary in" for the kernel
    > guys to appreciate what we have done, and using it as a general
    > guideline throughout will help meet that goal.
    
    Good.  "Best solution without other options or significant opposition."
    That's getting somewhere, although it prefers "first in" if nobody else
    can commit to an alternate solution within one business day.  Practically,
    that may be the most efficient way to proceed.
    
    > 
    > > Also, there are numerous different weights to voices... there must be.
    > 
    > Absolutely. But placing a weight on voices a priori isn't going to win
    > friends. :) If any interested reader can spot a problem, great. No
    > voting system will help in finding the problem, or solve the problem.
    
    Agreed.  Discussion before decision must be "level".  It allows the
    greater voices to interact with with lesser ones, perhaps modifying their
    opinion.  I never suggesting anybody's opinion should be discounted or
    ignored... but I do suggest a way to "carve" the final consensus in
    soap-stone (or even bubbles) will move us ahead faster. 
    
    > 
    > > Probably, but, suppose I'm the sort of guy who claims a problem with
    > > EVERYTHING ;-)  what problems are significant, what are not?
    > 
    > It depends upon the problem. :) Find one, guess at the level of damage
    > it may mean, and bring it up. Folks will either say "nope, not a
    > problem, the same <information, result, error> can be handled through a
    > <faster, smaller, more elegent> mechanism". Or folks will say, "ouch,
    > thanks for pointing this out", perhaps after some initial resistence. :)
    
    This is true, but I'd wager every single one of the 400+ people listening
    have a different test for "depends".  In this respect, though, the system
    we've BEEN using has had some real value...  
    
    Greg and Chris get to wear the "depends" :-)
    
    > 
    > The comment may or may not matter on its own merits, no matter who says
    > it, voting system or not to keep patches in or out, etc. I just don't
    > think it is worth the hassle to set up a voting scheme. :)
    
    The hassle isn't great.  A cgi and a disinterested referee.  Or even just
    a disinterested referee listening to the list... but if a "semi-informal"
    means can be imposed that works, I'm all for it.
    
    J. Melvin Jones
    
    |>------------------------------------------------------
    ||  J. MELVIN JONES            jmjonesat_private 
    |>------------------------------------------------------
    ||  Microcomputer Systems Consultant  
    ||  Software Developer
    ||  Web Site Design, Hosting, and Administration
    ||  Network and Systems Administration
    |>------------------------------------------------------
    ||  http://www.jmjones.com/
    |>------------------------------------------------------
    
    
    
    
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Mon Jul 23 2001 - 17:30:33 PDT