On 17/03/2026 8:14 am, Steven Wilton wrote:
On 17/03/2026 4:26 am, Tim Düsterhus wrote:
Hi
On 3/16/26 06:03, [email protected] wrote:
I believe that the process is to send a message to the list, and
gauge whether there is positive feedback before creating the RFC for
voting. Please let me know if I should create the RFC first?
The PR is here: https://github.com/php/php-src/pull/21452/changes
I suspect that SNMP is such a specialized and rarely used extension
that folks will be unable to meaningfully discuss an RFC for this
feature - at least not without you doing quite a bit of explaining.
This might be case where it's best to just find an informal agreement
with you providing a well-tested and well-explained patch rather than
doing a full RFC.
I'm very happy to avoid the RFC process, and happy to explain/discuss
the changes :)
On the topic of the RFC - @devnexen has suggested that a RFC is the
correct process for this change. I have no issues with following
whatever process is required to get this considered, but if most
maintainers won't be too concerned about changes to the module I am
interested who I should be discussing with that does know the code well
enough to make the decision on including it or not.
I have submitted a second PR below to add support for other SNMPv3
security protocols, and am wondering if I do end up going down the RFC
route whether it is best to merge everything into a single PR for "SNMP
changes", or if distinct changes should have their own PR with an
associated RFC?
https://github.com/php/php-src/pull/21451
While considering the previous question, I would like to add that I
would also like to add more options to control the output format. These
would just be duplicating the code for enum_print, quick_print and
oid_output_format. The question here is whether it should be a new
request with a new RFC, or if this is trivial enough to be considered
independently.
regards
Steve
