On Mon, 23 Jul 2001, Crispin Cowan wrote: > richard offer wrote: > > > Can someone please help me understand what the policies and procedures for > > accepting patches into the tree are ? > > Currently, only Chris (who works the LSM project for WireX) and Greg (who > used to work for WireX, but is now on his own dime) have write access to the > BK tree. The current ad hoc procedure is to convince one of them that a > patch is appropriate. This is rather more informal than I would like :-) > > I'd like to see something just a bit more inclusive. Perhaps some kind of 2 > phase commit, where Greg/Chris announce intent to apply a patch, and then > wait for ACK/NACK/Discuss responses? Critical question: who is critical to > get a response from. With over 400 people on the list, unanamous consent is > clearly out of the question :-) > > Linux manages this by giving Linus sole authority, but he listens to a lot of > people. I'm happy with Chris and Greg having the commit authority, but would > like to see a bit more opportunity for discussion before commit happens. > > So how about a 24-hour window between an announcement of "I'm going to commit > this" and actual commit? We are using a revision control system, so we can > back stuff out if necessary. And we can try it out with a meta experiment > applying the protocol to this proposal of mine. > > Crispin > > -- > Crispin Cowan, Ph.D. > Chief Scientist, WireX Communications, Inc. http://wirex.com > Security Hardened Linux Distribution: http://immunix.org > Available for purchase: http://wirex.com/Products/Immunix/purchase.html The window is handy, but it doesn't define when a patch will get the "ax" and when it will get accepted, except to give greg and chris "accept without being flamed" control. Also, to prevent "Friday" syndrome, I'd suggest making ONE BUSINESS DAY, not just 24 hours. I also don't see how you COULD get a majority consensus... since of those 400/500 people that are listening, about 20 are posting regularly... and I fully understand the "wait and watch" strategy of those who are not. Suppose we adopt a simple democratic system where every concern that has a pre-existing security product has one vote, and anybody else needs to get some number of sub-votes (say 5) to comprise one vote. This would seem, to me, to address the heavy cost to the pre-existing security vendors and the philosophy that LSM is an attempt to merge the needs of THOSE interests, while not excluding we "future module" creators, and the "armchair specialists". Simple reference to your project's web site, or not, would put you in catagory A or B. Any 1 (5 sub-votes) vote can get a patch put up for review. That would allow Chris to accept patches from catagory B for consideration, on behalf of wirex's 1 vote. If there was no rally against, it goes in. If there WAS, it would be weighted somewhat along the lines of the project's priorities. Weighted Majority Rules. Since I'm relegating myself to .2 votes, here, I want to at LEAST be considered as having thought it through. (LSMEXAMPLE would certainly NOT count.) There's still a minor element of trust here, but a more definite "technique" might reduce some fears and allow more distributed control of the project. Just a WILDLY DEMOCRATIC ideation, Would prefer to see a "razor test" that would get a patch in or out, 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 - 13:43:29 PDT