Re: CVS Account Request

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.