Re: [PHP-DEV] CVS Account Request From: John Donagher (john <email protected>)
Date: 11/15/00

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-----

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>