Re: Re: cvs: php4(PHP_4_0_5) /sapi/fastcgi

At 22:19 21/3/2001, Jason Greene wrote:

If the exception policy was in place here are some questions of thought: What would be necessary to make it safe to php in a whole?

I'd say that a module that has no effect on building PHP is fine to add as an experimental module. The only reason I believe we need at least one RC afterwards, is to ensure that trivial problems weren't introduced (mostly, a broken build).

What should the requirements be to allow this to happen ( ex. a lot of user demand, replaces something considered unstable) ?

I think that these are the same requirements for any other module that we decide to admit to the tree. Since it's not a big deal, if it belongs in the PHP 4.0 tree, then it's ok to add it whilst in RC's.

Should this require any re-testing? Should this require x amount of RCs to follow and how many?

IMHO, one more RC.

Should there be a vote on whether or not to allow the module in?

We don't have a body with 'jurisdiction' other than the PHP Group, so I'd say no; Whatever loose guidelines we use today to admit new modules can apply here as well.

Is this module something that should first be released as an add-on? I honestly agree with both positions on this one, and I think good can come from both of them : )

I think that by saying you agree with both positions you attribute to me things that I didn't say :) I'm all in favour of a stable release process. I'm not in favour in considering the release process guidelines as 'holy', and if I or anybody else thinks they can be improved, the right step would be to raise it for discussion. As I said to Hartmut, the minute bureaucracy becomes sacred, you know you're doing something wrong. I considered the fact that the release process did not account for new experimental modules a limitation of the release process. Even the US constitution required a few amendments before they got it right :) Zeev -- Zeev Suraski <zeev@zend.com> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/