Re: [RFC] php-community: a faster-moving, community-driven PHP.

> > >> For the first time, official binaries and packages will be provided for all major Linux >> distros for php-community releases on php.net > > Who is going to create and maintain these packages? Who decides which distros, which versions, > etc? Like sandboxing, this could fill an RFC on its own. > Initially me as the author of the RFC, then php-src maintainers. Splitting up this RFC into sub-RFCs is not an issue to me, but I would prefer to get a general positive consensus before spending more time on actual implementation. > >> Multiple versions of the same feature may be offered at the same time in a single >> php-community release > > How will this work, code-wise? Are these versions actually separate implementations side by > side, or limited to changes that can be represented with feature flags? > > What is the minimum lifetime and lifecycle of these versions? Can a version be retired early if > it has an unsolvable stability or security issue? > Clarified that this was mainly meant for removal/deprecation feature extensions. The exact lifecycle is explicitly not defined to allow for more flexibility, but it can have emergency yanks for security issues, just like for all extensions. > >> internals members through GitHub 👍 = Accept, 👎 = Reject, 👀 = Abstain reactions on >> the issue using their GitHub accounts, > > I don't think we have any suitable definition of "internals members" that can > apply here. Do you mean people with commit access to the php-src repo? Or are you hoping to > cross-check GitHub users against main.php.net accounts (as used by the current voting widget) > somehow? > By internals members I mean users with current voting rights, who will provide their GitHub nicknames. > >> A feature is eligible for removal only if both of the following conditions are met: >> - It has no active maintainer listed in the accepted community RFC design document. >> - Adoption is negligible, as evidenced by Packagist statistics. > > This feels incompatible with the rest of the process. If features are easy to propose, release, > and iterate, it should be just as easy to mark them abandoned or obsolete. Otherwise, an interesting > but flawed feature has to be maintained forever even if its author loses interest - and who is going > to do that maintenance? > > If the intention of these features is to be experimental, perhaps every feature version could > have a fixed lifetime. Users know that they can't rely on it long-term, but if it's > popular it will hopefully make it into a stable release of PHP. > The point here is that users MUST be able to rely on feature extensions, including in the long-term: this is the reason for the stringent removal requirements. > >> php-community will always be based on the latest stable PHP release > > Who will be responsible for merging changes made to "feature extensions" back to > master, and stabilising the first community release after a new stable release? > > The feature owners handle all changes to feature extensions. Normal PHP RMs handle merging stable PHP into the community branch. >> Community releases are “handled” by the same release managers of the latest stable PHP >> release, however the release process will be significantly automated, compared to the current manual >> release process > > Is there something that makes this automation easier for community releases than regular ones? > Or is automaton of the existing process something that needs to be done before we can consider this > RFC? > It can be applied to regular ones as well, but it was added mainly to work around the fact that normal PHP already has third-party distro packaging, while php-community will not, unless it is provided from the start by php.net <http://php.net/> directly. > >> Wait for the CI status of the new branch to become green > > If there are failing tests in a particular feature when it's time to tag a community > release, what happens? Does the release get delayed until the maintainer of that feature fixes it? > Feature maintainers cannot merge a failing PR, just like with all other php-src PRs. > >> php-community will live on a new community branch of php-src > > Who will be responsible for the stability of this branch? This is really important, because > you're targeting this concept at shared hosts, who want to know the software they're > running is stable and secure. > The feature authors, backed by the judgement of internals members and php-src maintainers. > Why will somebody trust this branch containing a bunch of separately-maintained feature > extensions any more than they would trust a repository of PIE extensions? If anything, it is far > *more* dangerous, because the features aren't limited to the normal extension API. Sandboxing plays the single most important rule in building trust. >> Note: the first community RFC may indeed be the one regarding the choice of appropriate >> sandbox keys. > > By definition, the sandbox mechanism needs to exist outside of the feature extension system, > and be stable across community versions. As others have said, it's basically independent of > this proposal, and should be its own RFC following the normal process. > Yes, absolutely. > > In other replies on this thread you've emphasised the role of feature maintainers, but the > RFC doesn't go into much detail about how that role will work. Will it be like maintaining a > PIE extension, committing code directly, but in a directory of php-src? Or are other members of the > community expected to review their code and merge it? > Clarified now, mainly it’s like maintaining a PIE extension committing code directly to php-src, with *some* supervision from php-src maintainers (mainly just a basic qualitychecks), crucially little impact on the actual API and design (which is the main way to reduce load on php-src maintainers). > > I think this RFC is trying to do two conflicting things at once: > > 1) allow users to test far-reaching, experimental, changes to the language and engine > 2) allow users to enable safe, stable, features without installing untrusted binaries > These are not conflicting things, they complement each other. > For problem 1, what we need is a way to get usable builds into the hands of users from > experimental branches of the source. If CI tooling and release packaging can be automated enough, > there's no reason to limit it to just one "community" branch. > Actually, the second php-community distro could theoretically be skipped altogether, shipping PhpFeatures into normal PHP, which would likely increase adoption even more. > For problem 2, we need stronger guarantees of stability, not weaker ones: better sandboxing so > people trust extensions more, perhaps; or more feature flags within the existing release cycle. Sandboxing is expected to cover this. > > Regards, Daniil Gentili.