Re: Voting periods

From: Date: Tue, 29 Jan 2013 17:23:59 +0000
Subject: Re: Voting periods
References: 1 2 3 4 5 6 7 8 9 10 11 12  Groups: php.internals 
Request: Send a blank email to internals+get-65422@lists.php.net to get a copy of this message
hi Larry, On Tue, Jan 29, 2013 at 5:55 PM, Larry Garfield <larry@garfieldtech.com> wrote: > On 1/29/13 5:08 AM, Pierre Joye wrote: >> >> hi Jan, >> >> On Tue, Jan 29, 2013 at 11:55 AM, Jan Ehrhardt <phpdev@ehrhardt.nl> wrote: >>> >>> Hi Pierre, >>> >>> Pierre Joye in php.internals (Tue, 29 Jan 2013 05:55:27 +0100): >>>> >>>> This is one of the reason why the 'new' release process RFC does not >>>> allow BC breaks. But we can't be 100% sure that we do not introduce >>>> one without you, all projects and users, doing intensive testing using >>>> your apps, modules, plugins, etc. And before the final releases, not >>>> after. >>>> >>>> Question: Did you test D7/8 and their respective plugins with php 5.5? >>> >>> >>> No. Reality: many Drupal users are beginning to move from Drupal 6 to >>> Drupal 7 at the moment. So are we. The code freeze for Drupal 8 will be >>> no sooner than July this year. And we have enough issues with D7 under >>> PHP 5.4 to worry about BC breaks beyond PHP 5.4. >> >> >> What do you need to get D7 tested under 5.5? I mean once you have a CI >> in place, it is not hard to setup one instance to test 5.5. >> >> Waiting the final release of 5.5 won't be of any help, not for Drupal, >> not for us. > > > Clear, detailed instructions aimed at someone who has *never used a C > compiler before*[1] for how to build, install, and run a 5.5 alpha, for Mac > and for common Linuxes[2], that do not require doing screwy things with > running multiple web servers on a single OS. In fact, the ideal would be > periodically released VirtualBox images with the latest alpha or beta tagged > that we can just boot up and run.[3] > > The first point is, I think, the biggest blocker. "Try out the latest PHP > and see what breaks" is currently a task that roughly 0.1% of PHP developers > have the technical ability to even do. Bring that up to 5-10% and we may > see a *much* better feedback loop.[4] > > [1] Really, I can count on one hand the number of Drupal developers who even > know C, much less can compile a complex C application. I'm sure you could > make all sorts of disparaging comments about Drupal/Drupalers as a result, > and you'd be about 1/3 right, but nonetheless that's the situation. > > [2] Drupal people are about 2/3 Macophiles, 1/3 Linux-istas, and > occasionally we let a Windows user in so that we don't look discriminatory. > I don't know how that breaks down in other major sub-communities. > > [3] We have a CI system in place but it's home grown, doesn't have enough > human resources maintaining it, and I don't think it supports multiple > variants of the PHP environment well. Yes, this is a problem. We're aware > of that, but I don't expect it to change soon, unfortunately. > > [4] As I am not part of that 0.1% I don't have much if any ability to help > improve that number, or I would offer to do so. My C-fu is about 8 years > old and was limited to Palm OS. Zero skills are required to setup a PHP. But a bit more clue is required to test Drupal. I can help the PHP setup automation but would need your help to setup D7+ setup with major plugins to automate the tests. By the way, we already do it with Drupal 7 using the default install in our labs (OSTC at Microsoft), regression, performance and functional, with and without APC, on IIS and Apache, nts and zts. We will add the o+ to the stack asap as well. See the following links for example results: http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20130125-5.5.0alpha4-5.5rd86e14b.html Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

« previous php.internals (#65422) next »