Hello! > However, this proposal would put a completely unrealistic burden on php-src > maintainers.
It seems to me this is an organizational problem that certainly has a good solution. In my company we also use something similar. In practice it does not require that much effort. Moreover, right now I am doing essentially the same thing for the TrueAsync project: - the php-src code is updated - tests are run - if the tests pass, the code proceeds further I am doing this manually, although the process could be automated. TrueAsync currently has about 18,000+ lines of changes in PHP-SRC. Over these six months my personal attention was required only 2–3 times. I can confirm a similar experience with other projects as well. A large number of different solutions can be devised here, both at the level of flow and rules, and at the level of technical approaches. So yes, it is a problem. But it is a problem that has a solution. > There's no real veto for php-src maintainers, This question is more complex. I personally prefer the models used by Go and Python, which rely on consensus rather than voting. I would only add a long path of iterative development, where a feature reaches users at an early stage. Releasing a feature early is what provides quality guarantees, something that is well confirmed by modern IT practice. Building a quality product using the scheme “first we design an RFC here → then nobody can actually implement it” has historically not worked well. Companies spent millions of dollars on this approach in the 1960s–70s, and the percentage of successful projects built this way was extremely small. This applies not only to the async project. Generics and most moderately complex features are in the same boat. > I honestly think this would be catastrophic. Not impossible. Although using statistics and real-world usage to evaluate features is definitely useful. The question is how to use it most effectively. I think this requires some thought. Best regards, Ed
