|>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ On Mon, 23 Jul 2001, Seth Arnold wrote: > I don't think Crispin intended for one day to be all the time allowed > for preparation of a competing proposal -- just that one day is enough > time to let someone look at a proposal and possibly complain if the idea > seems inadequate or misguided. Before I respond to HIS message (relax, the caps are a intended to be verbal emphasis, not an acknowlegement of Deity. ;) I studied Shakespeare in a grammatical/lexical context at one point in my life and got into the habit of using punctuation to queue the verbal rendition of my written word, rather than to indicate more "classical" forms of implied meaning.) I'm not entirely sure this is true. For example, the patches to net_dev... most people seemed to be "elsewhere" occupied... the discussion thereabout was quite thin. I'd rather not see a system that forces people to scream "NO" without following it through, but also would like to see a system that one can point to and "argue" in a general sense that their rejection was "inappropriate." AGAIN, beats me how to implement one... so far, wirex's moderation seems to go farther toward this than most "more definitive" systems I've ever heard of. Ideal vs. Practical... I think we have a "practical case" optimimum, although if any of the 400+ better minds can come up with a better one, I won't turn a deaf ear. > > The actual process of replacing the 'faulty' patch could possibly take > weeks. True, although... the rub I've seen is as follows: 1) a patch is submitted 2) it's rejected for possibly good reasons 3) the coder goes way back into the cave and tries to address those reasons... 4) the coder comes back "weeks" later, and the conversation has moved so far that (s)he's got to start from ground zero again. Somebody says "the consensus was to reject this approach." I suspect the only required response to this sequence is to create a "conditional acceptance/rejection state" with us somehow continuing to provide discussion and feedback to the submitter who is reworking his patch for review... thereby creating three states: 1) no way, this is dumb, nobody can see any benefit, why are you sending this, um, you stink! 2) rejected for explicit, potentially solvable reasons. Good effort. Let's work as a group to bring it in line with the "common goal" 3) ACCEPTED! MAN, are you BRILLIANT! (gross exagerations intended) (^_^) > > Waiting more than one day is going to slow the project down too much. We > want to have something to take to 2.5.x for some small value of x. ;) > But one day should be enough for someone to at least make a rough guess > if the patch looks good or not. > > Does this answer the question? (Or was it intended for other members of > the list? I can be quite self-centered when I feel like it. :) Yes. It's a good answer. I also see the "pre-consensus" period as being very variable. Once a consensus is achieved, I think SOMEBODY (Dr. Cowan, Dr. Smalley, Chris, Greg?) should "sum it up" and present a limitted time toward acceptance. This is similar to Dr. Cowan's original comments... but adds the "sum it up" requirement. > > Cheers! :) > Salut! 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 : Tue Jul 24 2001 - 15:40:42 PDT