Thank you. And yeah I have been thinking of the Redmine route myself.
The committers list will likely be small enough where a distributed
model like git or bzr is not needed.

Sent from my iPhone

On Nov 23, 2009, at 6:57 PM, Mathew Davies <thepixeldeveloper@googlemail.com
> wrote:

> Hi,
>
> I have not read the whole discussion but I would like to put redmine
> forward for the new and improved website. It comes with a bug
> tracker, repository browser, wiki, files and forums (everything you
> are looking for). I have used it on a personal project and having
> all the material in one place makes management easier. If you ever
> get round to getting something up and running I would be glad to
> lend a helping hand.
>
> Also, I do not think Michael should be condemned for being
> enthusiast. Just because he created a facebook page it does not mean
> you all have to sign up, it is just another means of communication
> for the PHP-FPM users which can only be a good thing in the long run?
>
> 2009/11/23 Michael Shadle <mike503@gmail.com>
> Yeah - that's why it says "go to launchpad right now, we're working on
> this" or something. I just need to figure out if a) we have the
> historical syncing to /downloads/ setup properly, and b) what the
> latest stable version actually is.
>
> changelogs and such may not exist. however, if we switched to using
> something like redmine or something, or possibly used launchpad more
> efficiently, we could link directly to something showing all the
> tickets that were fixed in that release.
>
> I'll talk w/ dreamcat about how to best handle that right now.
>
> On Mon, Nov 23, 2009 at 7:15 AM, Momchil Ivanov <slogster@gmail.com>
> wrote:
> > На понеделник 23 ноември 2009
> 11:56:24 Michael Shadle написа:
> >> Momchil, et al:
> >>
> >> I've thrown together a very quick template to get things started.
> >>
> >> Some information off the wiki will be moved to the normal
> website, so
> >> the wiki can be purely for user additions and edits.
> >>
> >> I might change the developer stuff over to something else than
> >> launchpad perhaps. We'll have to see about that. I might discuss
> with
> >> dreamcat4 since he's been contributing code and patches.
> >>
> >> Also need to fill in more information and such and flush things
> out.
> >>
> >> Please give it a good run through. Any navigation ideas? Any
> issues?
> >> This is where the *constructive* criticism helps. I am asking for
> it
> >
> > Now we are talking :) This looks more like a project page with the
> most
> > relevant project information listed. I like it.
> >
> > The only thing that bothers me is the link to the code, it would
> be better if
> > under "Latest Stable Release" you put the number, a direct link
> for download
> > and a link to the changelog. You can also point out: Old Stable
> Releases and
> > current development code can be found under http://launchpad.net/php-fpm
> . It's
> > important that people know what is the last stable release (as
> identification
> > number), a direct link to it and what has been changed since the
> previous
> > release. A direct link to the current dev/snapshot is also a good
> thing for
> > testers.
> >
> > Momchil
> >
>

I'd vote for git just for the same reason of distributed nature of potential
committers.

2009/11/23 Michael Shadle <mike503@gmail.com>

> Thank you. And yeah I have been thinking of the Redmine route myself. The
> committers list will likely be small enough where a distributed model like
> git or bzr is not needed.
>
> Sent from my iPhone
>
> On Nov 23, 2009, at 6:57 PM, Mathew Davies <
> thepixeldeveloper@googlemail.com> wrote:
>
> Hi,
>
> I have not read the whole discussion but I would like to put redmine
> forward for the new and improved website. It comes with a bug tracker,
> repository browser, wiki, files and forums (everything you are looking for).
> I have used it on a personal project and having all the material in one
> place makes management easier. If you ever get round to getting something up
> and running I would be glad to lend a helping hand.
>
> Also, I do not think Michael should be condemned for being enthusiast. Just
> because he created a facebook page it does not mean you all have to sign up,
> it is just another means of communication for the PHP-FPM users which can
> only be a good thing in the long run?
>
> 2009/11/23 Michael Shadle < <mike503@gmail.com>mike503@gmail.com>
>
>> Yeah - that's why it says "go to launchpad right now, we're working on
>> this" or something. I just need to figure out if a) we have the
>> historical syncing to /downloads/ setup properly, and b) what the
>> latest stable version actually is.
>>
>> changelogs and such may not exist. however, if we switched to using
>> something like redmine or something, or possibly used launchpad more
>> efficiently, we could link directly to something showing all the
>> tickets that were fixed in that release.
>>
>> I'll talk w/ dreamcat about how to best handle that right now.
>>
>> On Mon, Nov 23, 2009 at 7:15 AM, Momchil Ivanov < <slogster@gmail.com>
>> slogster@gmail.com> wrote:
>> > На понеделник 23 ноември 2009 11:56:24 Michael Shadle написа:
>> >> Momchil, et al:
>> >>
>> >> I've thrown together a very quick template to get things started.
>> >>
>> >> Some information off the wiki will be moved to the normal website, so
>> >> the wiki can be purely for user additions and edits.
>> >>
>> >> I might change the developer stuff over to something else than
>> >> launchpad perhaps. We'll have to see about that. I might discuss with
>> >> dreamcat4 since he's been contributing code and patches.
>> >>
>> >> Also need to fill in more information and such and flush things out.
>> >>
>> >> Please give it a good run through. Any navigation ideas? Any issues?
>> >> This is where the *constructive* criticism helps. I am asking for it
>> >
>> > Now we are talking :) This looks more like a project page with the most
>> > relevant project information listed. I like it.
>> >
>> > The only thing that bothers me is the link to the code, it would be
>> better if
>> > under "Latest Stable Release" you put the number, a direct link for
>> download
>> > and a link to the changelog. You can also point out: Old Stable Releases
>> and
>> > current development code can be found under
>> http://launchpad.net/php-fpmhttp://launchpad.net/php-fpm. It's
>> > important that people know what is the last stable release (as
>> identification
>> > number), a direct link to it and what has been changed since the
>> previous
>> > release. A direct link to the current dev/snapshot is also a good thing
>> for
>> > testers.
>> >
>> > Momchil
>> >
>>
>
>

Well so far we have a total of 1. Maybe 2 if Andrei popped out of the
woodwork to throw something in. Does github do bug tracking etc? Or
does redmine have git capabilities? I'm thinking we could still stick
with svn. People contributing in a git fashion can submit patches that
committers can review and/or commit...

Sent from my iPhone

On Nov 23, 2009, at 7:39 PM, Khazret Sapenov <sapenov@gmail.com> wrote:

> I'd vote for git just for the same reason of distributed nature of
> potential committers.
>
> 2009/11/23 Michael Shadle <mike503@gmail.com>
> Thank you. And yeah I have been thinking of the Redmine route
> myself. The committers list will likely be small enough where a
> distributed model like git or bzr is not needed.
>
> Sent from my iPhone
>
> On Nov 23, 2009, at 6:57 PM, Mathew Davies <thepixeldeveloper@googlemail.com
> > wrote:
>
>> Hi,
>>
>> I have not read the whole discussion but I would like to put
>> redmine forward for the new and improved website. It comes with a
>> bug tracker, repository browser, wiki, files and forums (everything
>> you are looking for). I have used it on a personal project and
>> having all the material in one place makes management easier. If
>> you ever get round to getting something up and running I would be
>> glad to lend a helping hand.
>>
>> Also, I do not think Michael should be condemned for being
>> enthusiast. Just because he created a facebook page it does not
>> mean you all have to sign up, it is just another means of
>> communication for the PHP-FPM users which can only be a good thing
>> in the long run?
>>
>> 2009/11/23 Michael Shadle <mike503@gmail.com>
>> Yeah - that's why it says "go to launchpad right now, we're working
>> on
>> this" or something. I just need to figure out if a) we have the
>> historical syncing to /downloads/ setup properly, and b) what the
>> latest stable version actually is.
>>
>> changelogs and such may not exist. however, if we switched to using
>> something like redmine or something, or possibly used launchpad more
>> efficiently, we could link directly to something showing all the
>> tickets that were fixed in that release.
>>
>> I'll talk w/ dreamcat about how to best handle that right now.
>>
>> On Mon, Nov 23, 2009 at 7:15 AM, Momchil Ivanov
>> <slogster@gmail.com> wrote:
>> > На понеделник 23 ноември 2009
>> 11:56:24 Michael Shadle написа:
>> >> Momchil, et al:
>> >>
>> >> I've thrown together a very quick template to get things started.
>> >>
>> >> Some information off the wiki will be moved to the normal
>> website, so
>> >> the wiki can be purely for user additions and edits.
>> >>
>> >> I might change the developer stuff over to something else than
>> >> launchpad perhaps. We'll have to see about that. I might discuss
>> with
>> >> dreamcat4 since he's been contributing code and patches.
>> >>
>> >> Also need to fill in more information and such and flush things
>> out.
>> >>
>> >> Please give it a good run through. Any navigation ideas? Any
>> issues?
>> >> This is where the *constructive* criticism helps. I am asking
>> for it
>> >
>> > Now we are talking :) This looks more like a project page with
>> the most
>> > relevant project information listed. I like it.
>> >
>> > The only thing that bothers me is the link to the code, it would
>> be better if
>> > under "Latest Stable Release" you put the number, a direct link
>> for download
>> > and a link to the changelog. You can also point out: Old Stable
>> Releases and
>> > current development code can be found under http://launchpad.net/php-fpm
>> . It's
>> > important that people know what is the last stable release (as
>> identification
>> > number), a direct link to it and what has been changed since the
>> previous
>> > release. A direct link to the current dev/snapshot is also a good
>> thing for
>> > testers.
>> >
>> > Momchil
>> >
>>
>

2009/11/24 Michael Shadle <mike503@gmail.com>:
> Well so far we have a total of 1. Maybe 2 if Andrei popped out of the
> woodwork to throw something in. Does github do bug tracking etc? Or does
> redmine have git capabilities? I'm thinking we could still stick with svn.

Redmine can track commits from a git repository but can't create
repository and host repository with it. You can keep the github
repository and tell Redmine to look into it to track changesets. You
can also do that tracking with svn/mercurial/bzr and many others.

--
Pierre Massat

Pierre Massat wrote:
> 2009/11/24 Michael Shadle <mike503@gmail.com>:
>
>> Well so far we have a total of 1. Maybe 2 if Andrei popped out of the
>> woodwork to throw something in. Does github do bug tracking etc? Or does
>> redmine have git capabilities? I'm thinking we could still stick with svn.
>>
>
> Redmine can track commits from a git repository but can't create
> repository and host repository with it. You can keep the github
> repository and tell Redmine to look into it to track changesets. You
> can also do that tracking with svn/mercurial/bzr and many others.
>
> --
> Pierre Massat
>

I wonder if you all know that sourceforge provides all those goodies..
Why not just host in SF?

2¢,

Hugo Monteiro.

I'm open to ideas. I originally choose launchpad because I've been
hanging out with the Drizzle crowd, who are all seasoned developers
who have contributed to almost every major open source project that
the web 2.0 stack uses...

They decided on bzr and launchpad, and I believe MySQL has switched
over to LP too; Ubuntu uses it (it would make sense) and it does have
bug reporting, feature requesting (blueprints, which can be tied to
milestones) and a built-in translation interface.

However, it is hosted offsite, and projects like those have hundreds
of developers. Even if we can get PHP-FPM pretty busy, I think we'd
have probably 10 developers at the most at any given time. Even if the
wishlist or other bugs/ideas are in full development mode, there is
not a lot of code to manage, really.



On Tue, Nov 24, 2009 at 4:55 AM, Hugo Monteiro <monteiro.hugo@gmail.com> wrote:
> Pierre Massat wrote:
>>
>> 2009/11/24 Michael Shadle <mike503@gmail.com>:
>>
>>>
>>> Well so far we have a total of 1. Maybe 2 if Andrei popped out of the
>>> woodwork to throw something in. Does github do bug tracking etc? Or does
>>> redmine have git capabilities? I'm thinking we could still stick with
>>> svn.
>>>
>>
>> Redmine can track commits from a git repository but can't create
>> repository and host repository with it. You can keep the github
>> repository and tell Redmine to look into it to track changesets. You
>> can also do that tracking with svn/mercurial/bzr and many others.
>>
>> --
>> Pierre Massat
>>
>
> I wonder if you all know that sourceforge provides all those goodies.. Why
> not just host in SF?
>
> 2¢,
>
> Hugo Monteiro.
>
>

> However, it is hosted offsite, and projects like those have hundreds
> of developers. Even if we can get PHP-FPM pretty busy, I think we'd
> have probably 10 developers at the most at any given time. Even if the
> wishlist or other bugs/ideas are in full development mode, there is
> not a lot of code to manage, really.

Right, but don't you think it could be even more usefull if PHP-FPM is
finally integrated into PHP? I talked to Andrey yesterday he explained
me that long story with PHP-team in details (what was before 0.6) but
it seems like they are always open for discussions. If FPM is
integrated into PHP - there could be much more develeopers involved
into the process and all these things like partial 5.3 incompatibility
et cetera - this will be fixed much much more quickly.

--

wbr,
fisher

He had a meeting right before 0.6 and came out of it with the same
direction it seems like.

To me I'm a bit scared that if it gets into php core that it will
stagnate especially if the management features are trying to be
tweaked. I mean how often is a php release out? And how long does it
take for the distros to upgrade?

Sent from my iPhone

On Nov 24, 2009, at 11:32 PM, "Alexey A. Rybak"
<alexey.rybak@gmail.com> wrote:

>> However, it is hosted offsite, and projects like those have hundreds
>> of developers. Even if we can get PHP-FPM pretty busy, I think we'd
>> have probably 10 developers at the most at any given time. Even if
>> the
>> wishlist or other bugs/ideas are in full development mode, there is
>> not a lot of code to manage, really.
>
> Right, but don't you think it could be even more usefull if PHP-FPM is
> finally integrated into PHP? I talked to Andrey yesterday he explained
> me that long story with PHP-team in details (what was before 0.6) but
> it seems like they are always open for discussions. If FPM is
> integrated into PHP - there could be much more develeopers involved
> into the process and all these things like partial 5.3 incompatibility
> et cetera - this will be fixed much much more quickly.
>
> --
>
> wbr,
> fisher

So in between minor PHP releases, you could always release patch updates.

On Wed, Nov 25, 2009 at 1:38 AM, Michael Shadle <mike503@gmail.com> wrote:
> He had a meeting right before 0.6 and came out of it with the same direction
> it seems like.
>
> To me I'm a bit scared that if it gets into php core that it will stagnate
> especially if the management features are trying to be tweaked. I mean how
> often is a php release out? And how long does it take for the distros to
> upgrade?
>
> Sent from my iPhone
>
> On Nov 24, 2009, at 11:32 PM, "Alexey A. Rybak" <alexey.rybak@gmail.com>
> wrote:
>
>>> However, it is hosted offsite, and projects like those have hundreds
>>> of developers. Even if we can get PHP-FPM pretty busy, I think we'd
>>> have probably 10 developers at the most at any given time. Even if the
>>> wishlist or other bugs/ideas are in full development mode, there is
>>> not a lot of code to manage, really.
>>
>> Right, but don't you think it could be even more usefull if PHP-FPM is
>> finally integrated into PHP? I talked to Andrey yesterday he explained
>> me that long story with PHP-team in details (what was before 0.6) but
>> it seems like they are always open for discussions. If FPM is
>> integrated into PHP - there could be much more develeopers involved
>> into the process and all these things like partial 5.3 incompatibility
>> et cetera - this will be fixed much much more quickly.
>>
>> --
>>
>> wbr,
>> fisher
>

On Wed, Nov 25, 2009 at 7:24 PM, Gordon Pettey <petteyg359@gmail.com>
wrote:
> So in between minor PHP releases, you could always release patch updates.

+1
plus: most of the features people really need are already in fpm
and many proposed features were in todo years ago and are in todo now ;)

--

wbr,
fisher

2009/11/25 Alexey A. Rybak <alexey.rybak@gmail.com>:
> On Wed, Nov 25, 2009 at 7:24 PM, Gordon Pettey <petteyg359@gmail.com>
> wrote:
>> So in between minor PHP releases, you could always release patch updates.
>
> +1
> plus: most of the features people really need are already in fpm
> and many proposed features were in todo years ago and are in todo now ;)
>

In my mind, there is two different things.

php-fpm is a huge patch to php-cgi. Even if the executable is called
php-fpm, it's a patched version of php-cgi. So the question is "does
PHP team wants all functions from php-fpm to be integrated into php
core" ? If so, php-fpm will be integrated into php one way or the
other. (Will php-cgi be an application server as tomcat is ? this is
the real question !!!)

If PHP team does not want all functions from PHP-FPM, php-fpm must be
a kind of php-cgi manager. For this to work, some function must be
integrated into php-fpm (like chroot) while the others (like dynamic
process launching depending on load) will be done by php-fpm.

Or PHP doesn't want any of php-fpm function .. in this case, php-fpm
will always be a php-cgi fork.

The simplest way, in my mind, is to identified precisely php-fpm
functions which have to be integrated into PHP and which one will be
required to allow php-fpm to work. And then it'll be much more easy to
deal with php-fpm.

hope it helps some way

Sorry but that would be the wrong way around.

There's nothing against adding fpm SAPI to the upstream source. In 5.3
we already have 20 different SAPI in php-src/sapi folder. So what hell
difference will +1 more sapi there make? Answer: none. Some time after
the PHP sapi is settled in the php code, then later you may come along
and do whatever you like, clean it up, dissecting it. Whatever. But
inbetween then and now you just can't go around depriving so many
other people from compiling the current fpm and using it. It really
doesn't matter whether you think fpm is ready to be the official one
yet or not.

And i simply repeat exactly how Alexey says - just release the patch
updates in between. Its 3 times easier that way around. Hang on, no.
"its like 5.3 times easier" i should say. (thats supposed to be meant
as a small joke). Anyway the real truth is its up to PHP group whether
they have enough free time to merge the fpm code into 5.3.

End of discussion.

2009/11/25 Jérôme Loyet <ml@fatbsd.com>:
> 2009/11/25 Alexey A. Rybak <alexey.rybak@gmail.com>:
>> On Wed, Nov 25, 2009 at 7:24 PM, Gordon Pettey <petteyg359@gmail.com>
>> wrote:
>>> So in between minor PHP releases, you could always release patch updates.
>>
>> +1
>> plus: most of the features people really need are already in fpm
>> and many proposed features were in todo years ago and are in todo now ;)
>>
>
> In my mind, there is two different things.
>
> php-fpm is a huge patch to php-cgi. Even if the executable is called
> php-fpm, it's a patched version of php-cgi. So the question is "does
> PHP team wants all functions from php-fpm to be integrated into php
> core" ? If so, php-fpm will be integrated into php one way or the
> other. (Will php-cgi be an application server as tomcat is ? this is
> the real question !!!)
>
> If PHP team does not want all functions from PHP-FPM, php-fpm must be
> a kind of php-cgi manager. For this to work, some function must be
> integrated into php-fpm (like chroot) while the others (like dynamic
> process launching depending on load) will be done by php-fpm.
>
> Or PHP doesn't want any of php-fpm function .. in this case, php-fpm
> will always be a php-cgi fork.
>
> The simplest way, in my mind, is to identified precisely php-fpm
> functions which have to be integrated into PHP and which one will be
> required to allow php-fpm to work. And then it'll be much more easy to
> deal with php-fpm.
>
> hope it helps some way
>

So, we're still out there on our own saying "here's a newer version of
PHP-FPM, patch it against your core PHP code?"

Seems kinda hokey to me but two people voted that they liked that.

Let me pose this a different way, and this seems to be almost a
religious discussion now...

What if we got the PHP team to integrate the pieces needed for PHP-FPM
to manage php-cgi properly, using direct API hooks or even just
command line options, but any of Andrei's accelerated upload support
stuff, the script termination/timeout, backlogging, all that, and got
that into PHP core, and had a separate thing that was just the
daemon/config file/any functionality that doesn't need to be in PHP
core?

That would provide an easy way to use PHP-FPM as it would be just a
standalone daemon using PHP core functionality, but it could be
released as production builds and whatnot whenever we wanted to
release it.

For example, adaptive process spawning is most likely everyone's #1
"when will this be done" question. I know it's been mine since day one
of using PHP-FPM. However, what if the necessary hooks were in PHP
core and all the logic to do the math on the request counts and such
was done inside of PHP-FPM?

To me this allows for people to choose the daemon to control their
processes if they want. In theory, someone else could fork or improve
upon PHP-FPM, reverse engineer or copy the command line options, etc.
That's fine with me. It's all open source anyway. :) However, this
could allow package managers to treat it like spawn-fcgi or something
of that nature - completely independent of PHP itself, but lets us
continue to improve PHP-FPM by itself and not rely on anything from
the PHP core team.

(Note: this is just my "idea" - I have no clue how expensive it would
be from a programming/IPC angle, but I think it provides a clear
separation between the daemon and management and allows for the PHP
core to be patched only once and included in the mainstream, and only
true bugs or issues or missing things needed by PHP-FPM would require
any more changes after that)

What would everyone think about -that- approach?

Obviously it'd be great if it was just part of PHP but I don't want to
have to continuously say "okay, you were using stock PHP 5.3 from your
Ubuntu repo. But now you have to uninstall that, download the PHP
source, patch it using the updated PHP-FPM patch until it becomes part
of PHP core, if you want these features"

Instead you could just download a single .deb file of the PHP-FPM
daemon to upgrade. It could be hosted officially by Ubuntu (whenever
it gets pushed up the stream) but people could grab it from anywhere -
PPAs or even self-hosted repositories we could build and host
ourselves.

I'm trying to think of it at the highest level possible.




On Wed, Nov 25, 2009 at 8:24 AM, Gordon Pettey <petteyg359@gmail.com> wrote:
> So in between minor PHP releases, you could always release patch updates.
>
> On Wed, Nov 25, 2009 at 1:38 AM, Michael Shadle <mike503@gmail.com> wrote:
>> He had a meeting right before 0.6 and came out of it with the same direction
>> it seems like.
>>
>> To me I'm a bit scared that if it gets into php core that it will stagnate
>> especially if the management features are trying to be tweaked. I mean how
>> often is a php release out? And how long does it take for the distros to
>> upgrade?
>>
>> Sent from my iPhone
>>
>> On Nov 24, 2009, at 11:32 PM, "Alexey A. Rybak" <alexey.rybak@gmail.com>
>> wrote:
>>
>>>> However, it is hosted offsite, and projects like those have hundreds
>>>> of developers. Even if we can get PHP-FPM pretty busy, I think we'd
>>>> have probably 10 developers at the most at any given time. Even if the
>>>> wishlist or other bugs/ideas are in full development mode, there is
>>>> not a lot of code to manage, really.
>>>
>>> Right, but don't you think it could be even more usefull if PHP-FPM is
>>> finally integrated into PHP? I talked to Andrey yesterday he explained
>>> me that long story with PHP-team in details (what was before 0.6) but
>>> it seems like they are always open for discussions. If FPM is
>>> integrated into PHP - there could be much more develeopers involved
>>> into the process and all these things like partial 5.3 incompatibility
>>> et cetera - this will be fixed much much more quickly.
>>>
>>> --
>>>
>>> wbr,
>>> fisher
>>
>

2009/11/25 Michael Shadle <mike503@gmail.com>:
> So, we're still out there on our own saying "here's a newer version of
> PHP-FPM, patch it against your core PHP code?"
>
> Seems kinda hokey to me but two people voted that they liked that.
>
> Let me pose this a different way, and this seems to be almost a
> religious discussion now...
>
> What if we got the PHP team to integrate the pieces needed for PHP-FPM
> to manage php-cgi properly, using direct API hooks or even just
> command line options, but any of Andrei's accelerated upload support
> stuff, the script termination/timeout, backlogging, all that, and got
> that into PHP core, and had a separate thing that was just the
> daemon/config file/any functionality that doesn't need to be in PHP
> core?
>
> That would provide an easy way to use PHP-FPM as it would be just a
> standalone daemon using PHP core functionality, but it could be
> released as production builds and whatnot whenever we wanted to
> release it.
>
> For example, adaptive process spawning is most likely everyone's #1
> "when will this be done" question. I know it's been mine since day one
> of using PHP-FPM. However, what if the necessary hooks were in PHP
> core and all the logic to do the math on the request counts and such
> was done inside of PHP-FPM?
>
> To me this allows for people to choose the daemon to control their
> processes if they want. In theory, someone else could fork or improve
> upon PHP-FPM, reverse engineer or copy the command line options, etc.
> That's fine with me. It's all open source anyway. :) However, this
> could allow package managers to treat it like spawn-fcgi or something
> of that nature - completely independent of PHP itself, but lets us
> continue to improve PHP-FPM by itself and not rely on anything from
> the PHP core team.
>
> (Note: this is just my "idea" - I have no clue how expensive it would
> be from a programming/IPC angle, but I think it provides a clear
> separation between the daemon and management and allows for the PHP
> core to be patched only once and included in the mainstream, and only
> true bugs or issues or missing things needed by PHP-FPM would require
> any more changes after that)
>
> What would everyone think about -that- approach?

I totaly agree with this approach. I have nothing else to add (for now) :)

>
> Obviously it'd be great if it was just part of PHP but I don't want to
> have to continuously say "okay, you were using stock PHP 5.3 from your
> Ubuntu repo. But now you have to uninstall that, download the PHP
> source, patch it using the updated PHP-FPM patch until it becomes part
> of PHP core, if you want these features"
>
> Instead you could just download a single .deb file of the PHP-FPM
> daemon to upgrade. It could be hosted officially by Ubuntu (whenever
> it gets pushed up the stream) but people could grab it from anywhere -
> PPAs or even self-hosted repositories we could build and host
> ourselves.
>
> I'm trying to think of it at the highest level possible.
>
>
>
>
> On Wed, Nov 25, 2009 at 8:24 AM, Gordon Pettey <petteyg359@gmail.com> wrote:
>> So in between minor PHP releases, you could always release patch updates.
>>
>> On Wed, Nov 25, 2009 at 1:38 AM, Michael Shadle <mike503@gmail.com> wrote:
>>> He had a meeting right before 0.6 and came out of it with the same direction
>>> it seems like.
>>>
>>> To me I'm a bit scared that if it gets into php core that it will stagnate
>>> especially if the management features are trying to be tweaked. I mean how
>>> often is a php release out? And how long does it take for the distros to
>>> upgrade?
>>>
>>> Sent from my iPhone
>>>
>>> On Nov 24, 2009, at 11:32 PM, "Alexey A. Rybak" <alexey.rybak@gmail.com>
>>> wrote:
>>>
>>>>> However, it is hosted offsite, and projects like those have hundreds
>>>>> of developers. Even if we can get PHP-FPM pretty busy, I think we'd
>>>>> have probably 10 developers at the most at any given time. Even if the
>>>>> wishlist or other bugs/ideas are in full development mode, there is
>>>>> not a lot of code to manage, really.
>>>>
>>>> Right, but don't you think it could be even more usefull if PHP-FPM is
>>>> finally integrated into PHP? I talked to Andrey yesterday he explained
>>>> me that long story with PHP-team in details (what was before 0.6) but
>>>> it seems like they are always open for discussions. If FPM is
>>>> integrated into PHP - there could be much more develeopers involved
>>>> into the process and all these things like partial 5.3 incompatibility
>>>> et cetera - this will be fixed much much more quickly.
>>>>
>>>> --
>>>>
>>>> wbr,
>>>> fisher
>>>
>>
>

I haven't looked at the code, and I don't know C, but I don't see how
having "some" code in core is any better than the current
patched-source method. How can you guarantee that future features of
FPM will never need additional code supported in core PHP, in which
case you either have to wait for the next minor version or patch it
yourself, anyway?

I can't guarantee that. Note that I said php core will only need to be
modified if there is a bug or something additional needed or missing.
However we have a good idea of what it needs right now and for the
future based on the wishlist.

Remember. This is not just for those daring enough to patch php and
recompile it themselves but for package management with all the repos.
For companies which only allow supported software from repositories
this will help greatly for example.



Sent from my iPhone

On Nov 25, 2009, at 2:25 PM, Gordon Pettey <petteyg359@gmail.com> wrote:

> I haven't looked at the code, and I don't know C, but I don't see how
> having "some" code in core is any better than the current
> patched-source method. How can you guarantee that future features of
> FPM will never need additional code supported in core PHP, in which
> case you either have to wait for the next minor version or patch it
> yourself, anyway?

Seems like I started to miss something :) OK, imagine that PHP-FPM
goes into PHP repo

- being different SAPI additional to those twenty PHP already has
- compiled with PHP as easy as enable-fpm or whatever and goes into
all deb pkg or whatever automatically!
- has a huge user base cause now it's part of PHP
- has to be synchronized with PHP development cycle which means that
there are some frozen periods when you can't commit new features

Isn't it the best future for the project at this point when we at
russian list get messages like "hey guys seems like you have a lot of
C-developers so common become fpm maintaners!" :))) ?

Well, let's be honest. Most of features FPM has now - are OK for most
of users. What we need mostly - support for new versions of PHP and
bugfixes for different platforms. This all can be done easily when FPM
is a part of PHP.

The only one big feature is apache like blabla. If I have to chose
between good support for old features plus huge popularity vs what we
have now (with a big respect to all guys mike and dreamcat and
everybody who works on the project) - I choose first, just because all
the minuses like "independence" could be minuses if FPM was in a very
very active development stage - which is not true.


On Thu, Nov 26, 2009 at 2:18 AM, Michael Shadle <mike503@gmail.com> wrote:
> I can't guarantee that. Note that I said php core will only need to be
> modified if there is a bug or something additional needed or missing.
> However we have a good idea of what it needs right now and for the future
> based on the wishlist.
>
> Remember. This is not just for those daring enough to patch php and
> recompile it themselves but for package management with all the repos. For
> companies which only allow supported software from repositories this will
> help greatly for example.
>
>
>
> Sent from my iPhone
>
> On Nov 25, 2009, at 2:25 PM, Gordon Pettey <petteyg359@gmail.com> wrote:
>
>> I haven't looked at the code, and I don't know C, but I don't see how
>> having "some" code in core is any better than the current
>> patched-source method. How can you guarantee that future features of
>> FPM will never need additional code supported in core PHP, in which
>> case you either have to wait for the next minor version or patch it
>> yourself, anyway?
>



--

wbr,
fisher

I do agree that by getting it into the core it would be upgraded and
such but what if you got the best of both worlds? :p

Sent from my iPhone

On Nov 27, 2009, at 7:29 AM, "Alexey A. Rybak"
<alexey.rybak@gmail.com> wrote:

> Seems like I started to miss something :) OK, imagine that PHP-FPM
> goes into PHP repo
>
> - being different SAPI additional to those twenty PHP already has
> - compiled with PHP as easy as enable-fpm or whatever and goes into
> all deb pkg or whatever automatically!
> - has a huge user base cause now it's part of PHP
> - has to be synchronized with PHP development cycle which means that
> there are some frozen periods when you can't commit new features
>
> Isn't it the best future for the project at this point when we at
> russian list get messages like "hey guys seems like you have a lot of
> C-developers so common become fpm maintaners!" :))) ?
>
> Well, let's be honest. Most of features FPM has now - are OK for most
> of users. What we need mostly - support for new versions of PHP and
> bugfixes for different platforms. This all can be done easily when FPM
> is a part of PHP.
>
> The only one big feature is apache like blabla. If I have to chose
> between good support for old features plus huge popularity vs what we
> have now (with a big respect to all guys mike and dreamcat and
> everybody who works on the project) - I choose first, just because all
> the minuses like "independence" could be minuses if FPM was in a very
> very active development stage - which is not true.
>
>
> On Thu, Nov 26, 2009 at 2:18 AM, Michael Shadle <mike503@gmail.com>
> wrote:
>> I can't guarantee that. Note that I said php core will only need to
>> be
>> modified if there is a bug or something additional needed or missing.
>> However we have a good idea of what it needs right now and for the
>> future
>> based on the wishlist.
>>
>> Remember. This is not just for those daring enough to patch php and
>> recompile it themselves but for package management with all the
>> repos. For
>> companies which only allow supported software from repositories
>> this will
>> help greatly for example.
>>
>>
>>
>> Sent from my iPhone
>>
>> On Nov 25, 2009, at 2:25 PM, Gordon Pettey <petteyg359@gmail.com>
>> wrote:
>>
>>> I haven't looked at the code, and I don't know C, but I don't see
>>> how
>>> having "some" code in core is any better than the current
>>> patched-source method. How can you guarantee that future features of
>>> FPM will never need additional code supported in core PHP, in which
>>> case you either have to wait for the next minor version or patch it
>>> yourself, anyway?
>>
>
>
>
> --
>
> wbr,
> fisher