php-developer-list | 2000111
Date: 11/15/00
- Next message: waldschrott <email protected>: "[PHP-DEV] PHP 4.0 Bug #7621 Updated: NULL-bytes cause fundamental problems in string processing"
- Previous message: Zeev Suraski: "Re: [PHP-DEV] CVS Account Request"
- In reply to: Zeev Suraski: "Re: [PHP-DEV] CVS Account Request"
- Next in thread: Zeev Suraski: "Re: [PHP-DEV] CVS Account Request"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> >No I didn't, the commit message is still unread in my inbox due to a heavy
> >travel schedule, but chances are I wouldn't have caught it when I got back
> >and started chewing through my mailbox anyway. But are you seriously
> >suggesting that because he had an overflow in his extension he should not
> >have had commit access? Onn works for Zend and Andi vouched for him and
> >created his CVS account. Those a pretty good credentials and I don't care
> >how much we tighten rules, Onn would still have gotten a CVS account and
> >he would still have committed an extension that contained a buffer
> >overflow so I don't see how this does anything to prove your point.
>
> Well, his code didn't have a buffer overflow, it was just an example. I
> think it's pretty unreasonable that you'd be able to go over the CVS
> updates that piled up in your mailbox in any remotely efficient way. It's
> not human, and I don't blame you for not doing that. That is why we should
> try to reduce the chances of problems occurring there to begin with. You
> don't have to wait for the problem to have negative symptoms before you try
> to reduce it.
But how do we do that? By reducing the number of commits? That doesn't
sound like the right answer to me.
> >As long as it can be done without adding extra hurdles for legitimate
> >contributions I am fine with it. ACL's make sense. But I am leary about
> >any sort of review-then-commit type of approach as per Sterling's
> >suggestion. It puts an extra workload on existing contributors and
> >introduces delays for potential new contributors.
>
> I think that a startup period for new comers is not a bad idea in
> general. It should be a fairly short period, it can be extremely short (a
> few days, a couple of weeks at most). If you see patches flowing in from
> that guy, and they look ok, it means two things - he's unlikely to be a
> hacker, and he's probably in a real need for a CVS account. Today, we have
> no clue about these two issues at all, and he's granted a CVS account
> almost automatically.
That's not entirely true. Yes, doc people and lately pear people have had
semi-automatic cvs accounts created. I have had dozens of exchanges with
people wanting to contribute to the codebase before setting up the cvs
account. But we could formalize this and write it down somewhere.
-Rasmus
-- 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>
- Next message: waldschrott <email protected>: "[PHP-DEV] PHP 4.0 Bug #7621 Updated: NULL-bytes cause fundamental problems in string processing"
- Previous message: Zeev Suraski: "Re: [PHP-DEV] CVS Account Request"
- In reply to: Zeev Suraski: "Re: [PHP-DEV] CVS Account Request"
- Next in thread: Zeev Suraski: "Re: [PHP-DEV] CVS Account Request"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

