2011/8/24 Ferenc Kovacs <tyr...@gmail.com>: > 2011/8/24 Johannes Schlüter <johan...@schlueters.de>: >> On Wed, 2011-08-24 at 12:24 +0200, Ferenc Kovacs wrote: >>> we could have spotted this via two ways: >>> - those who participated in fixing >>> https://bugs.php.net/bug.php?id=53727 could have spotted this >>> - our tests should have start failing after the change >> >> Third option: >> - RC testers might have spotted and reported it. >> >> I have the impression that very few people actually test these. When >> creating an RC we inform the "primary testers" as well as qa and >> internals list members. From there I get one or two responses in >> general. >> >> When I approach PHP users I often get answers like installing PHP >> without breaking their setup would be complicated (which is not the case >> but maybe needs education?) and they won't have time. I try to use a >> hypothetical case, like we have here in reality, to explain them why it >> is beneficial for their business if it is detected early as then we can >> fix it, fixing something after a release is hard. We also can try to >> improve our tests but we will never be able to test each and every way >> PHP is being used out there in the wild. >> >> >> So how can we motivate people to test new versions during RC not the day >> after it is being released? >> >> >> We don't push them out as news on the php.net frontpage and we don't >> send it out to the announce list for reasons like not confusing users. >> Should we change that? Other ideas? >> >> johannes > > agree, should have mentioned that. > I think that currently testing the RCs have a very high barrier. > usually they are going unnoticed for most people and compiling your > own version (with all the extensions that you need) can be really > cumbersome. > - we need to get out the word to the masses (the current php.net site > simply lacks this, maybe the http://prototype.php.net/ will be better > in this regard), for which we also need to lower the barriers to > entry: > - better documentation about how to build your own php version would > be a must, maybe phpfarm can be also useful for this
I would really glad to have a script that will be eager to enable as much modules as it can find on my machine (plus enable debug flags as --enable-zts-maintainer and such) and even offer to install some missing dependencies from OS packages (I'm on ubuntu so it's easy to do some apt-get/yum install if you know what are you for). For now you have to read quite a long list of configure options and then install their dependencies which are quite non-obvious to find out. > - we should cooperate with the major php projects out there to run > their testsuites against the new releases or maybe even trunk, if I > remember correctly somebody mentioned that we already do this for some > projects (maybe Pierre mentioned this). this would be an easy way to > boost our test coverage and make the BC breaks more obvious. > - having pre-packaged versions of php available would also help, > testing out the latest mysql versions are much more easy for example, > as I can just grab the Linux - Generic archive, extract it, and voila, > I can test it. > - projects like http://apt.damz.org/ also help > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
