From: Stanislav Malyshev on
Hi!

> A little notice about ZS in general, "community" or not:
>
> - it has nothing to do with php.net
> - we don't support it (don't report bugs to bugs.php.net using it)

I think it's a little overreaching. It has a lot to do with php.net -
it's the same code, only compiled. And I don't think it makes any sense
to refuse handling bugs in builds other than php.net build - we never
did it and that never was a policy of bugs.php.net. So if there's a bug
in PHP which manifests in ZS build (of course, without Zend extensions
etc.) then it should be reported to bugs.php.net as bugs in all other
builds do, and please do report it.
--
Stanislav Malyshev, Zend Software Architect
stas(a)zend.com http://www.zend.com/
(408)253-8829 MSN: stas(a)zend.com
From: Pierre Joye on
On Sat, Oct 24, 2009 at 8:23 PM, Stanislav Malyshev <stas(a)zend.com> wrote:
> Hi!
>
>> A little notice about ZS in general, "community" or not:
>>
>> - it has nothing to do with php.net
>> - we don't support it (don't report bugs to bugs.php.net using it)
>
> I think it's a little overreaching. It has a lot to do with php.net - it's
> the same code, only compiled.

It is not as far as I can see and it does not use the same libs either
on windows.

> And I don't think it makes any sense to refuse
> handling bugs in builds other than php.net build - we never did it and that
> never was a policy of bugs.php.net.

We always did.

Cheers,
--
Pierre

http://blog.thepimp.net | http://www.libgd.org
From: Shahar Evron on
I am very biased (full disc., I'm the technical PM of Zend Server) but
let me try to answer some of this, and maybe some of the concerns that
have been raised in this thread (and in other places). I'm trying to be
as transparent as possible, maybe this will help you decide whether or
not ZSCE is for you.

Zend Server CE provides a stable and well preforming PHP setup on
Windows. You can get that setup through other means of course, but this
is our focus for Zend Server.

I'd also say that up until now we are mostly focused on providing a
production stack. Hence the opcode cache, FastCGI setup, etc.

As for Oracle support, we bundle the Oracle client libraries (lite
version actually) and compile oci8 and PDO_OCI against the 11g libraries
to support the new DRCP feature.

As for compatibility and non-standard build, this might imply several
things and I can only guess what specific issues people are referring
to, but if I'm guessing right, there are two differences between how we
build PHP and the php.net binaries:

* Usage of VC8 vs. VC9 or VC6 - Zend has been building on Windows with
VC8 for a couple of years now (since Zend Core). This makes our PHP
builds somewhat incompatible with VC6 built extension DLLs for PHP 5.2
(we know they mostly work, but there's definitely a difference), and
completely incompatible with VC6 or VC9 builds on PHP 5.3 (because PHP
simply won't load them).

We are in the process of moving all our build system to use VC9 (yes,
that's official) and in fact the PHP 5.3 builds of Zend Server 5.0 beta
(not yet available in CE) are already on VC9. Eventually we will ship
all our 5.3 builds on VC9.

My note on this would be that if you need some custom extension which
is not shipped by Zend Server, check first if it works or not - if
you'll be using 5.3 than you'll have to wait for us to release VC9 based
builds. If you have everything you need shipped with Zend Server, then I
don't think there's real concern there - except for being able to report
bugs to bugs.php.net which I will not get into, as I am not really a
core developer and have no say here. Of course, if you report these bugs
to Zend we will take them seriously :)

* Zend does apply some patches to PHP which are not a part of official
php.net releases. Those fall under two categories:

1. Patches already in the php.net SVN tree, but not released yet. We
do this when we encounter some major bug or security issue in PHP and
decide it's important enough for us to patch it in our own product. This
is done very selectively and in any case the only patches applied are
already in the PHP source tree - we simply backport them.

2. Patches that provide Zend Server specific functionality, such as
fixes that help our own specific FastCGI infrastructure to work better.
This is done in a very local and minimal manner, and shouldn't affect
the behavior of your own PHP code.

Again, I think the only concern here for you as an end user (and not a
core PHP developer) is the fact that bugs reported through bugs.php.net
might not be accepted. Again, I have no say to whether this is right or
wrong, I am not a core developer and can't judge. As I said you can
always report these bugs to Zend, we can triage and figure out if it's a
PHP bug or a Zend induced bug, and fix accordingly (and push to php.net
if relevant).


Ok, I think I have said enough :) I'll be happy to answer more
questions, on or off the list.

Best regards,

Shahar.

Marcos R. Cardoso wrote:
> Does anyone here have any opinion about Zend Server Community Edition?
>
> I'm doing some tests here and I'm intending to use it at the University
> Library where I work.
>
> Any input about this web application would be nice.
>
> TIA,
>

--
Shahar Evron <shahar.e(a)zend.com>

Product Manager
Zend Technologies
From: Pierre Joye on
hi,

The only fact that you build 5.2 with VC8 means that you apply patches
not present in php 5.2 (eventually in 5.3).

About moving to VC9 for 5.3, given that we have moved to VC9 and
everything is going well so far, that sounds like a logical move.

But why would you provide your own binaries with random patches (not a
judgement, only a statement) instead of using PHP binaries? Security?
We do security releases when a librarie is affected. PHP itself has
regular security releases as well. For example, Microsoft uses
php.net's binaries for the Web Platform Installer
(http://www.microsoft.com/web/).

Other comments inline,

On Tue, Oct 27, 2009 at 5:51 PM, Shahar Evron <shahar.e(a)zend.com> wrote:

>  2. Patches that provide Zend Server specific functionality, such as
> fixes that help our own specific FastCGI infrastructure to work better.
> This is done in a very local and minimal manner, and shouldn't affect
> the behavior of your own PHP code.

Your own FastCGI to work better than what?


> Again, I think the only concern here for you as an end user (and not a
> core PHP developer) is the fact that bugs reported through bugs.php.net
> might not be accepted. Again, I have no say to whether this is right or
> wrong, I am not a core developer and can't judge. As I said you can
> always report these bugs to Zend, we can triage and figure out if it's a
> PHP bug or a Zend induced bug, and fix accordingly (and push to php.net
> if relevant).

As being both my concerns are to actually see a kind of fork of PHP,
being presented as the only usable binary distributions for windows
and other platforms (and for apache too).

As with any distributors who apply custom patches, we do not support
them. However these distributors usually have an issues tracker and
ask their users to report issues there. If they meet a real php bug,
it is then then reported in our tracker. That's common practice. We
will indeed not reject obvious bugs only because the users use ZS.

Cheers,
--
Pierre

http://blog.thepimp.net | http://www.libgd.org
From: Stanislav Malyshev on
Hi!

> As being both my concerns are to actually see a kind of fork of PHP,
> being presented as the only usable binary distributions for windows
> and other platforms (and for apache too).

There's no any "fork" and nobody ever presented it as "the only usable
binary distributions for windows".
Applying patches between releases is how most of binary distros always
worked (provided there are patches important for their clients which are
not released yet) with a lot of opensource projects - incl. Redhat, etc.
- and nobody ever thought of talking about "forking" anything.
--
Stanislav Malyshev, Zend Software Architect
stas(a)zend.com http://www.zend.com/
(408)253-8829 MSN: stas(a)zend.com