Re: CVS Account Request

This seems to imply and require a far higher level of commitment than that required to contribute to most open-source projects I've seen. If we are going to go this far (i.e. sponsoring cvs accounts, requiring a web of trust) it seems more natural just to ask people to submit patches to a select group of cvs account holders and do away with all the regulations. John On Wed, 15 Nov 2000, Ron Chmara wrote: > As far as _establishing_ and _maintaining_ that trust, I like some of the ideas > already posed, and I'll add some additional ones: > > 1. "Commits to the mailing list(s)" before gaining actual commit access. > > 2. Establishing a human/personal presence on the list(s) before gaining access. > It should be required that the other members of the CVS teams can at least > rationally converse with you before you can modify their code. A CVS commit > user _must_ follow the dialog on the lists they're in, so they don't commit > blindly, causing an uproar. > > 3. Anonymous accounts and remailers (yahoo, hotmail, etc.) should _never_ be > allowed commit access. If they aren't of a competancy level to at least have > control of their servers, they shouldn't be able to modify ours. > > 4. Keep the "back room" (the core list) for negotiating the items of personality, > for *final say* on new CVS accounts. > > 5. De-activate accounts that have been idle for so long that the core team no > longer recognizes their names, or can remember a recent commit. > > 6. Communicate off list. This is about creating trust relationships. Get to > know your peers in your given area. Learn their communication patterns, learn > to spot the "real thing" in those requesting commit access. > > 7. Make the biggest barrier the first one. A lot of the tasks involved in > open source software building require crossing boundaries in your working > areas, and we can (and should) encourage people to grow into as many tasks > as they can do competently.... which means the front door is the most > important one. > > 8. Sponsoring in new CVS account users. This means that before a person > could get commit access, they've at least earned the trust of one person > who's been here long enough to have an interest in keeping the project > on the right track. There doesn't need to be much in the way of overhead > for this, just somebody willing to say "hey, I've been working with this > guy for a week or two, he seems on the level, his code is okay". > > But as far as securing sections of the code/doc/web: > /phpweb folks could compromise the site, /phpdoc folks could do the same, /php4 > folks could compromise the code base itself. > > Of the 3, the scariest AFAICT (for cracker targets) would be /phpweb simply > because it's the most "public" face of PHP. A code compromise in /php4 > would be a bug, followed by a fix no biggie. A website hack is instantly on > slashdot, and maybe even CNN. > > > Now while one > > of the reasons many people contribute to PHP is because it is so easy to > > get involved with the development, really most of the commits are only made > > by a handful of people (PHP Group and a 10-20 others, if even). Most of > > the users could simply send patches. Patches make sure the code is qa'ed, > > and then, if the patches are approved (by a committer) then they would be > > committed, after a while if the user is someone who is constantly sending > > (good) patches he would then obtain a cvs account to commit to the code > > repository (documentation could be given less security). > > See above arguments about why /phpdoc and /phpweb matters, in some ways > *more* than /php4. > > -ROn > > -- > Brought to you from boop!, the dual boot Linux/Win95 Compaq Presario 1625 > laptop, currently running RedHat 6.1. Your bopping may vary. > > -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBDnCZ1oRBACFgkFCV6p3dWic1qm1FLhip5beIyzZSt+ccTDYQQdPZA/t5H+k PZ7ZFBIUrXz/oEqwQwlEKlg8JQqg7hgtcL+xrIJ0BInLeSJG4lvvB551g59Thr7/ OsdxNVxKci775+K+GkdAz4xcULMuB+QE7t665Ri46EAS8ALos5UG6DGmhwCguD0v 1cxwy/KlKr+oi4sWM9caueED/RmjiSD3vmBZQt6PMisVe1AmkEf6cJoemduCSJxu 0eMz/LIeu+CqfpuJH2N/dZ3hRj9xMSHF4l71wKqV99zhm58kDGwG1u3yVzULPDqz 0yL+8nunlkoOUyn3zOnh3Zmz4POFVMZQ5oian3QkLllUwly5JCi5tWULxZ2vOkb0 zzjuA/4jigNxYV4NAyCl+wAbnyzk9/Iz8EHv4/0Ex8ytlcMtvBJKa9HjJxlyIl74 yOILHk3+GSAdM0b3ZmbavpoCpebinOMBhqEVBwCI4VUIAqf86gx+2dKBGxfKPnU4 Xxvqs/BOl/EbeJjyd4uieYndGRaWg+kYXqZ7SxrlFN24fohnd7QgSm9obiBEb25h Z2hlciA8am9obkB3ZWJtZXRhLmNvbT6IVgQTEQIAFgUCOcJnWgQLCgQDAxUDAgMW AgECF4AACgkQIt6tVu6+jd3SHwCgjssFktMXf8NjE9JBR+sJ2gDIsW8An0CFNdFd dU+DJYC6ogYP9AsVfM27uQENBDnCZ2MQBAD8E0qe1gBKjtoRmyiyORtwhOz/2XZE mqiZN2NouAUWRRZd4dHggFAA1jUsp2MVIZZQyY9ajNVy3Oaxj5kYz8LR5GItxxcD jC8RFXKM40ZfTJeR7fH6eJa689w+le71Tt4ALyN4xcjSWuksr8795AhHFjonDi8D rgGIq6GtWvi/KwADBgQAmeBbcjPzhqR2M8TdvEyNfVTQSSp/RNoTjNNWpHui8V0p kiQ49tbsqeMjXGToGgMugfmrX77JidXyuVjgYjT9xUdaaA25qKAR75M9izDliT7Y h5L+QZTAw0/5X9go7XK3WI3LYfFrp4TP0veXgSWxDqccqsRzWKW7IoXsliTCbVqI RgQYEQIABgUCOcJnYwAKCRAi3q1W7r6N3YIcAKCkJMTPLu6tOPnXPl2s3xmnSawy BACeOx83WlBhVScYWo+BUzntJ6ks4T0= =OkJU -----END PGP PUBLIC KEY BLOCK-----