Re: [PHP-DEV] CVS Account Request From: Ron Chmara (ron <email protected>)
Date: 11/15/00

Summarization/Continuation (though I think we may have exhausted the
discussion, and need to start implementing decisions):

Zeev Suraski wrote:
> At 01:47 16/11/2000, Ron Chmara wrote:
> > At the least, every once in a while the inactives should be turned off.
> I agree with that as well (not necessarily because of brute force attacks
> though). The freeze up time can be very long (a year), but it is a good
> idea to have it.

Does anybody see a problem with this (turning off inactives)? Do we
just need criteria on "inactivity"? Is a year good for everyone?

> >It's a blurry line, and it's more blurry for
> >the people who are more active. And while people may be more active in
> >some areas than others, that shouldn't neccesarrily revoke their ability
> >to work in a given area. (I can't remember the last time I saw Zeev or
> >Andi commit docs, should they loose perms to /phpdoc? er....)
> Right. Frankly, I don't mind losing phpdoc access, if I'll need it -
> regaining it won't be too problematic. Last time I committed docs was back
> in 1998, I think :)

Summary of opinions to date:
Maybe split it. If we do split it, allow for intelligent boundary crossing.
We don't have a large problem right now, but it is a problem that we
currently contend with in small ways, and as the contributors increase,
the problems will likely increase to match. The lines of splitting
seem to cut roughly between code, doc/web, and project entities (pear, qa).

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

Nobody seems to disagree with this one. So to implement it, I'd like
to suggest the following (abd if nobody objects, I'll do it tomorrow):
A) Add this information to the CVS sign-up page.
B) Send out a standard email to those requesting access that they should
initially make list-based "commits".

> >2. Establishing a human/personal presence on the list(s) before gaining
> >access.
> I think that would be problematic to implement, even though it would have
> been very good if it was.

True. Suffice to say that this dialogue has, at least for a while, raised a
public reminder that CVS folks needs to at least be somewhat clueful and
communicative. Putting the CVS requests onto this list at least provides
a starting ground, where the request can be evaluated, and new commits
and patches can be discussed. If new folks are required to post patches
to the list beforehand anyways (as above), it will at least begin the process.

Upon consideration, I also realize that sometimes brilliant code comes
from people with poor social skills. I don't think we should sacrifice
good code possibilities just because somebody does not "play well with
others". :-)

> >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.
> Hehe, well, I don't really agree with that one... Getting an account at an
> ISP for a few bucks isn't exactly rocket science...

No, it isn't. But it does raise the bar to require for-pay services, and
more importantly, a loss of *some* anonymity. If it's an ongoing account,
(for list commits, then CVS) there will be a paper audit trail, back to
a human being, or a reasonable facsimilie threof.

> >4. Keep the "back room" (the core list) for negotiating the items of
> > personality, for *final say* on new CVS accounts.
> I'm not sure that's such a good idea. I find php-dev to be quite a bit
> more responsive and versatile, due to its nature - it's a much broader
> list. I don't think we'd get to situations where we're really uncertain of
> whether or not we should add someone to the CVS write access.

I was thinking more in terms of reaching a solution in cases of deadlock
or vehement dissent. This is a big issue in the US right now. :)

I think it's fair to say that if somebody was severeley opposed, and
explained why, that the php-dev list can hash something out, but
having a "higher-power backup plan" doesn't hurt.

> >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.
> That would close too many accounts for no good reason :)

Er... above you seem to agree... I guess the difference is one of freezing
accounts based on a certain timeframe, vs. human memory. Again, does anyone
have objections to freezing (not deleting) accounts that have been inactive
for over a year?

> >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".
> That's a great way of introducing new people.

There has been one objection to this, in that it raises the bar to make
it difficult to directly commit by people who are new. Since their
commits would likely have to be pre-screened anyways (if initial patching/adding
required list posts), this might add an additional formality to regular
contributors... but I was actually thinking that this could ease the
commit process, where Zeev or Rasmus or whomever could work off list
for a while with somebody, and then "sponsor" them in. It also creates
a requirement for at least *some* trust being established before giving
somebody commit permissions.

In some ways, this isn't new, it's just publicizing the decisions which
were already being made by Rasmus et. al., as well as opening up the
process a bit to inspire more communication and mentoring (good term).

> A code hack can translate to an exploit affecting tens of thousands of
> sites on the net. A much bigger CNN piece - almost as big as the piece
> they'd make if they find Thies's face on Al Gore's site :)

Microsoft's code never seems to be blamed for the IIS hacks..

Are you telling me I should be checking algore.com on a frequent basis?
:)

_ronabop 

--
Brought to you from iBop the iMac, a MacOS, Win95, Win98, LinuxPPC machine,
which is currently in MacOS land.  Your bopping may vary.

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