Depending on the changes whether they are more enhancements or showing
stopping bug fixes, could they not be withdrawn and put in as first changes
for 4.0.6?
> -----Original Message-----
> From: James Moore [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, April 22, 2001 5:01 PM
> To: Sascha Schumann
> Cc: [EMAIL PROTECTED]; PHP Quality Assurance Team Mailing List;
> [EMAIL PROTECTED]
> Subject: RE: [PHP-QA] RE: [PHP-CVS] cvs: php4(PHP_4_0_5) /ext/ircg
> config.m4 ircg.c php_ircg.h
>
>
> > On Sun, 22 Apr 2001, James Moore wrote:
> >
> > > >
> > > > sas Sun Apr 22 08:17:57 2001 EDT
> > > >
> > > > Modified files: (Branch: PHP_4_0_5)
> > > > /php4/ext/ircg config.m4 ircg.c php_ircg.h
> > > > Log:
> > > > MFH allocation-related and thttpd-independence changes
> > >
> > > Sascha can you please STOP MFH'ding
> >
> > Well, that really surprises me. I commit minimal changes
> > while other people commit _huge_ patches to the release
> > branch and noone complains about that.
> >
> > Regardless, the changes I just committed are _all_
> > self-contained. They cannot affect anything else (beside the
> > single config.m4 change which has been merged from the head
> > branch). And hence, they are in good tradition with what has
> > happened up to now to the 4.0.5 branch.
>
> Sorry Sascha,
> I missed the com changes too, I just saw the thttpd and ircg changes..
>
> Herald I trust you will be helping to test RC8 too please dont MFH this late
> in the process and before you do so send a mail to PHP-DEV and PHP-QA
> justifying your changes and why they are so urgent that they require the
> delay of the release of PHP 4.0.5 is it really that necessary to fix the mem
> leak??
>
> TO both of you we have just tested RC7 please be realistic and if you
> changes REALLY need to be in 4.0.5 then thats OK and we will test again but
> if they are not critical then please revert the patches you are delaying
> the release of 4.0.5 further by forcing another RC cycle.
>
> Sascha looking at your patch:
>
> +PHP_FUNCTION(ircg_ignore_add)
> +{+#if defined(IRCG_API_VERSION) && IRCG_API_VERSION >= 20010402
> + zval **args[2];
> + php_irconn_t *conn;
> + smart_str s;
> +
> + if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_array_ex(2, args) ==
> FAILURE)
> + WRONG_PARAM_COUNT;
> +
> + convert_to_long_ex(args[0]);
> + convert_to_string_ex(args[1]);
> +
> + conn = lookup_irconn(Z_LVAL_PP(args[0]));
> + if (!conn) RETURN_FALSE;
> +
> + smart_str_setl(&s, Z_STRVAL_PP(args[1]), Z_STRLEN_PP(args[1]));
> + irc_ignore_add(&conn->conn, &s, 1);
> +#endif
> +}
>
> Would it not be better to have an else here the outputs a warning rather
> than having the possibility of
>
> PHP_FUNCTION(ircg_ignore_add)
> {
> }
>
> The same is true of:
> ircg_ignore_del
>
> and seemingly a lot of the IRCG functions..
>
> - James
>
>
> --
> PHP Quality Assurance Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
