There's been some thrash lately due to the new direction PHP-FPM has taken.

First off, I'd like to give a hearty thanks to dreamcat4 - who has
been patching and hacking on Andrei's new non-patch branch.

For everyone else, please be patient - we're trying to work on
publishing a versioning scheme that isn't confusing, I'm trying to
figure out how to reshuffle around information on the wiki, and we're
trying to push people to adopt the new style of PHP-FPM.

The last "official" patch to PHP-FPM was for 5.2.10. I've applied it
to 5.2.11, it whines about some configure offsets but that's it. It
seems to still work flawlessly.

However, we're no longer supporting the patch - don't expect any new
versions of the patch to come out. If people want to continue hacking
on that, feel free, and we can figure out some way for those links to
be posted (perhaps a "legacy version" page) - but dreamcat4's
definitely been working only on this new version and it is a much
better version and will be much easier as it morphs into something
that can be adopted into official repositories and/or the PHP SAPI
tree itself. That's still in discussion I believe.

For any older versions of PHP or any other unsupported configurations
we'll have to default with the advice of "use spawn-fcgi or php -b
$port with the appropriate environment variables under a supervisor
type daemon"

Anyway, please take note:

Main page for development: https://launchpad.net/php-fpm/
note: at the moment there's a slight conflict since dreamcat4's been
hacking away he's made a main page for it:
http://github.com/dreamcat4/php-fpm/ (we need to merge this
information back into one source)

Bugs: https://bugs.launchpad.net/php-fpm/

Wishlist/Feature Requests: https://blueprints.launchpad.net/php-fpm/
(I will be trying to move everything from http://php-fpm.org/Wishlist
over) - by putting these into the blueprint area on launchpad they can
be assigned, tracked and most importantly associated to specific
milestones.

Documentation/Community Contributed Notes: http://php-fpm.org/ (still
being reshuffled to make room for all the different versions now)

We're working on trying to utilize the resources out there better as
well, leveraging bug report emails and possibly merging it into this
list, etc.

If you've got any ideas please feel free to share them.

As always - contributions of any sort help: documentation, bug
reporting, money, buildbot test scripts (this could help a lot), and
of course, code!

I'm trying my best as a modest PHP guy, not a C guy, to keep the
project alive and always to get more exposure for it. This is truly
the best method to manage PHP if using it through FastCGI, hands down.

Thanks,
mike

Hi Mike,

One thing is not very clear for me, is it true that php-fpm is planned to be integrated in the official php package?

Thanks

There seems to be a religious debate about that. I want a hybrid
approach, but I think dreamcat's been working to try to get it aligned
for insertion. Problem is I don't think it would be in until another
bigger release down the line, official repos won't pick it up for a
long long time and I think it will stagnate development if we're stuck
with aligning with PHP releases.

I think APIs and the other SAPI fixes should be put into PHP core, and
then PHP-FPM should stay separate as a manager for it. That will keep
us able to be agile, change things around, add more features and such,
etc.

dreamcat may have some more light to shed on the subject, he's been
rattling the fences with the PHP SAPI team for a bit.

On Thu, Oct 1, 2009 at 2:17 AM, Revy <nginx-forum@nginx.us> wrote:
>
> Hi Mike,
>
> One thing is not very clear for me, is it true that php-fpm is planned to be integrated in the official php package?
>
> Thanks
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?3,9646,10443#msg-10443
>
>

On Thu, Oct 1, 2009 at 10:17 AM, Revy <nginx-forum@nginx.us> wrote:
>
> Hi Mike,
>
> One thing is not very clear for me, is it true that php-fpm is planned to be integrated in the official php package?
>
> Thanks

Well that depends on user demand and a lot of other factors.

Amongst other things, it's not possible to have an official debian
and/or ubuntu package without this. So basically for this reason, we
are submitting our code to the php team. Its a process known as
upstreaming. If you agree with this direction, then vote for FPM on
the official PHP Bug report: http://bugs.php.net/?id=49707

dreamcat4
dreamcat4@gmail.com

On Thu, Oct 1, 2009 at 5:54 PM, Michael Shadle <mike503@gmail.com> wrote:
>
> There seems to be a religious debate about that. I want a hybrid
> approach, but I think dreamcat's been working to try to get it aligned
> for insertion. Problem is I don't think it would be in until another
> bigger release down the line, official repos won't pick it up for a
> long long time and I think it will stagnate development if we're stuck
> with aligning with PHP releases.
>
> I think APIs and the other SAPI fixes should be put into PHP core, and
> then PHP-FPM should stay separate as a manager for it. That will keep
> us able to be agile, change things around, add more features and such,
> etc.
>
> dreamcat may have some more light to shed on the subject, he's been
> rattling the fences with the PHP SAPI team for a bit.

These are valid arguments, however it would probably be better to view
the php team as more of an additional pool of experience to draw upon.
Some very experienced developers who can help the fpm part go further.
I would also add that if an official fpm took too long, we could
easily and pretty quickly just update our external version and / or
contribute externally developed features back to php. We have taken
steps to ensure that will be as simple and straightforward as possible
in 0.6.

Personally, I cannot see much problems either way here.
We should be ready for any outcome.


dreamcat4
dreamcat4@gmail.com

voted :) .

Probably you can post the link in nginx group to get more votes

On Thu, Oct 1, 2009 at 11:05 PM, dreamcat four <dreamcat4@gmail.com> wrote:

>
> On Thu, Oct 1, 2009 at 10:17 AM, Revy <nginx-forum@nginx.us> wrote:
> >
> > Hi Mike,
> >
> > One thing is not very clear for me, is it true that php-fpm is planned to
> be integrated in the official php package?
> >
> > Thanks
>
> Well that depends on user demand and a lot of other factors.
>
> Amongst other things, it's not possible to have an official debian
> and/or ubuntu package without this. So basically for this reason, we
> are submitting our code to the php team. Its a process known as
> upstreaming. If you agree with this direction, then vote for FPM on
> the official PHP Bug report: http://bugs.php.net/?id=49707
>
> dreamcat4
> dreamcat4@gmail.com
>



--
Anoop P Alias (PGP Key ID : 0x014F9953)
GNU system administrator
http://GnuSys.net

On Thu, Oct 1, 2009 at 10:52 AM, dreamcat four <dreamcat4@gmail.com> wrote:

> These are valid arguments, however it would probably be better to view
> the php team as more of an additional pool of experience to draw upon.
> Some very experienced developers who can help the fpm part go further.
> I would also add that if an official fpm took too long, we could
> easily and pretty quickly just update our external version and / or
> contribute externally developed features back to php. We have taken
> steps to ensure that will be as simple and straightforward as possible
> in 0.6.
>
> Personally, I cannot see much problems either way here.
> We should be ready for any outcome.

But any contributions we would make back to PHP still follow the PHP
release process.

Being that PHP is a large project, they cannot have agile releases. If
things were put into place to manage FastCGI processes externally then
that could open up the FPM project to be agile - and even allow for
third party process management tools other than FPM in theory...

Hell, cpanel and other things could possibly take advantage of it for
resource limits and such!