>
> My understanding is that
> a) this creates a fork of PHP in the sense that a separate version has to be
> maintained
> b) you assume the same core developers will be in charge of the what I call
> "stable" and the "community" version of PHP
>
> Is that correct?
> This makes me worried about the additional burden on the core maintainers.
Yes, this is mostly correct: however note that the maintenance burden of
feature extensions will lay squarely on the feature maintainers/authors, listed
in the designed document of merged community RFCs.
Developers outside of the feature maintainers should only need to touch feature
extension code when introducing breaking changes to extension APIs, like is
already the case now for extensions.
This is actually very close to the approach used by linux: drivers are owned
and maintained each by their own maintainers: non-maintainers need to touch
driver code only when authoring breaking changes to inner Linux APIs which
affect drivers.
> as well as compatibility issues for package maintainers ("this library is
> only guaranteed to work with php-community-yyyy1-mm1-dd1 to
> php-community-yyyy2-mm2-dd2 but not the base php" or vice versa).
It is for precisely this reason that all feature extensions are versioned
(possibly with multiple versions of a single extension shipping in a single
php-community release), and full information about available versions is
exposed through the PhpFeatures class, in a format matching Composer JSON
repositories.
Package maintainers are expected to rely on specific versions of features
(feature-performance:^2), not on specific releases of php-community.
I initially even considered not exposing the current php-community version at
all to userland, exposing just the stable php version it is based on, but then
decided against it as there is still a small amount of non-feature extension
scaffolding code unique to php-community, which may have bugs, which may
require versioning (i.e. a bug the PhpFeature class itself).
Thinking about it some more, PhpFeature and scaffolding code may itself be
exposed as a versioned, always-enabled php-community feature extension, so now
that I think about it, exposing the current php-community version is even more
useless, but I’d still leave it exposed even if just for PR reasons.
>
> Another thing I am a bit confused about is the inclusion of sandboxing as
> part of this RFC: Is this really an integral part of the community version?
> And while we're at it: As long as the community version allows for
> PECL/PIE/whatever extensions then the sandboxing could be broken by those
> extensions, so this can lead to a false sense of security / needs auditing of
> all extensions included in a version. That's why I'm wary of including it as
> a secondary feature, it feels a bit tacked on to me for a security topic.
>
Sandboxing is expected to cover only features offered by mainline PHP,
php-community and all extensions and feature extensions shipping with PHP and
php-community, not normal extensions installed separately (though normal
extensions may choose to opt-in and respect sandboxing levels as well, if they
wish).
Sandboxing is indeed somewhat a separate matter from php-community, and can in
fact be fully defined by a separate (community or normal) RFC. However, it is
absolutely mandatory for the implementation of the main goal of php-community:
fast adoption of new features by the entire PHP community, especially shared
hosts, which require sandboxing by definition, and cannot be expected to look
through the list of changes in all feature extensions bundled in all of the
monthly releases of php-community.
In fact, IMO one of the reasons why shared hosts often lag behind PHP versions
is the (small, but non-negligible) cost of searching and patching sandbox
escape hatches introduced by new PHP versions, so sandboxing, if merged in
mainline PHP, may also speed up adoption of even normal PHP upgrades.
Regards,
Daniil Gentili.
