> > >> 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.
