At 16:48 10.1. 2001, Sam Liddicott wrote the following:
--------------------------------------------------------------
>I think it is more of (my guess, blame me if I'm wrong) there aren't enough
>active PHP developers for whom windows is the most important platform so
>that window problems don't get noticed as quickly as other problems and so
>don't get fixed as quickly and it ends up being the one system that appears
>to hold things back and (naturally) more often falls the other side of the
>cut off point.
>
>No-one is to blame for this, how can one point the finger and say "Windows
>should be more important to you than it is" although it is annoying.
Well, I didn't mean to sound like that. Although, actually, I guess we can
aggree that the amount of attention a platform recieves from developers is
(partially) proportional to the level of bugging they're exposed to. For
example, if I didn't keep on mailing the list (and even Zeev directly, in the
end), it'd've been about four weeks now PHP 4 wouldn't build mod_php4 on NT
because of the zend_ini_rshutdown / zend_ini_deactivate issue, and no one
would've noticed). Also, numbers from php4win.de show that the popularity of
win32 mod_php4 is steadily rising (more than 4800 downloads of 4.0.4 so far),
and these people will be quite disappointed if they realize that they're on
the wrong side of the fence... The point is: the less attention is paid to
any particular platform, the more users steer away from it, and with
decreasing number of users the attention of the developers will fade too.
Hm, I got carried away a bit... So, what I'm trying to say is:
I understand why win32 Apache (and mod_php4) recieves less attention than unix
one. I'd like to see this change, and so I at least point out build failures
when I encounter them. But it's quite frustrating to see a report (which, as
it turned out, required one #ifdef to solve) unnoticed for - how long? If I
didn't bite the bullet of risking I'll be stamped as a PITA and didn't mail
Daniel Beulshausen asking for help, it probably wouldn't build to date - two
weeks. Also, with the fast pace of PHP and Zend development, it might be
noticably harder to hunt down a bug after a week or two whereas it'd be easier
to do something about it e. g. the next day. For example, if this build
failure was fixed earlier than it was, 4.0.4pl1 RC's (and the release) could
build on NT. Unfortunately, there have been so many changes meantime that it
has to wait till 4.0.5 now.
I know I have to push a bit if I want to see win32 mod_php4 more supported,
and I'm willing to "put my money where my mouth is", as far as I can. That's
why I searched CVS logs to find the author of apache_child_terminate (you),
mailed you with the hint I was given by another developer.
>For instance I submitted the apache_child_terminate patch (edited via Sacha)
>but it did not work with apache under windows - well how many platforms
>build with *apache* in *multi-thread* mode?
I know, it was me who mailed you.
Only windows, AFAIK. I know thread safety adds to complexity of development,
and am offering (actually already trying to) help here. However, I certainly
don't want to find out one day a developer stops paying attention to win32
DSO because I pissed them off...
So, is it ok for me to try to keep win32 DSO 'healthy' by eventually bugging
a developer who is responsible for (authored) something that breaks the win32
build when posting a bug report doesn't help?
I can do it, if that is the way, but if the party line is 'we don't care about
win32 mod_php4 except perhaps major versions' I'll just shut up and hold my
breath... However, then it'll probably degrade to a scenario similar to this:
do {
'ok, we have 4.0.x RCy imminent, does win32 DSO build?'
'no'
'nevermind, let's roll it out anyway, we'll look into it later'
} while( till the 4.0.x is out, still failing to build )
The probability of compile failures/general bugs accross versions will certainly
increase, and it'll require more effort to make it build after considerably
longer period of time => larger amount of updates.
>It was picked up as a fault two weeks or more after the patch was submitted.
It took me two weeks to get to solving this one, because I couldn't build
mod_php4 for two weeks already at the time you submitted the function. If it
built I'd've let you know within two days.
>I avoid blame for this although my patch was deficient because I don't have
>a windows build environment.
Well, I was trying to be kind of unofficial QAT member building mod_php4 from
snaps.php.net often since last summer or so. I don't blame you (or anyone else
for that matter) for writing a function that breaks the build process on a
platform you don't have access to.
>I think just just an unforunate thing, once more developers value windows it
>will solve itself.
I'm trying to help make it happen.
>Sam
>
>> -----Original Message-----
>> From: Cynic [mailto:[EMAIL PROTECTED]]
>> Sent: Wednesday, January 10, 2001 02:19
>> To: Zeev Suraski
>> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>> Subject: Re: [PHP-DEV] 4.0.4pl1 RC2 rolled
>>
>>
>> Ok. I don't wanna be anyone's PITA, but is there something
>> like a list of priorities when it comes to this kind of stuff?
>> something like this:
>> 1) CGI on Linux must build no matter what
>> 2) mod_php4 on Linux must build no matter what
>> 3) CGI on other Unices should build
>> ...
>> x) win32 CGI should build
>> y) php4isapi.dll should build
>> z) win32 mod_php4 should build
>>
>> As I wrote in one of private mails to Zeev, I think win32
>> mod_php4 -> unix mod_php4 is the most natural (and easiest) way
>> of development for many, given you have the closest possible
>> environment, and win32 mod_php4 happens to be rock solid (when
>> it builds)... but I'm biased, of course.
>>
>> Anyway, it really seems like win32 mod_php4 has the lowest
>> priority of these, I think it would be otherwise available
>> from www.php.net next to the ISAPI binaries... (I'm aware of
>> php4win.de.)
>>
>> So, is there something like a list of priorities when it comes
>> to building platforms? And what is it based on?
>>
>> I think win32 mod_php4 would eat quite a portion of the ISAPI
>> pie if it was more known.
>>
>>
>>
>> At 14:51 10.1. 2001, Zeev Suraski wrote the following:
>> --------------------------------------------------------------
>> >I don't think it's crucial for 4.0.4pl1...
>> >
>> >Zeev
>> >
>> >At 15:46 10/1/2001, Cynic wrote:
>> >>4.0.4pl1 RC2 doesn't build as win32 mod_php4, so probably
>> >>the patch I bugged you in should be there as well?
>> >>
>> >>Linking...
>> >> Creating library ..\..\Release_TS_inline/php4apache.lib
>> and object ..\..\Release_TS_inline/php4apache.exp
>> >>mod_php4.obj : error LNK2001: unresolved external symbol
>> _zend_ini_rshutdown
>> >>..\..\Release_TS_inline/php4apache.dll : fatal error
>> LNK1120: 1 unresolved externals
>> >>Error executing link.exe.
>> >>
>> >>
>> >>
>> >>At 22:14 9.1. 2001, Zeev Suraski wrote the following:
>> >>--------------------------------------------------------------
>> >>>Only one change in this release - Daniel's PDF fixes were
>> merged in. If all goes well, I want to release pl1 in 48 hours.
>> >>>
>> >>>Zeev
>> >>>
>> >>>
>> >>>--
>> >>>Zeev Suraski <[EMAIL PROTECTED]>
>> >>>CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/
>> >>>
>> >>>
------end of quote------
--
PHP Development 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]
