Regarding contributions to this project

[lgrahl]

With my patch rejection rate being quite high I'm quite discouraged to contribute further, perhaps even more significant, changes in the future. Watching contributions from other folks, I may not be the only one being affected but I can only speak for myself.

A list of things that have been rejected where I at least need the first two ones:

• Configurable headroom of DTLS packets: Patch Make headroom of an outgoing DTLS packet configurable #161 has been rejected. Frankly, I don't see anything controversial about this.
• Handling of %h prefixed format specifiers: Path Handle %h prefixed (short) types #49 has been rejected. It wasn't entirely uncontroversial since re was not being written with PRI... macro compatibility in mind but IMO the patch was quite trivial and wouldn't have hurt.
• Set Diffie-Hellman parameters: Patch Set Diffie-Hellman parameters #35 has been rejected. However, a change has been introduced which exposed the OpenSSL context (which is also slightly controversial).

Features that I originally wanted to make a pull request for but I'm now very hesitant about because I fear they will be rejected as well:

• Headless DTLS: A virtual DTLS socket that is not attached to any socket. Work originally started in Use one DTLS connection for multiple UDP sockets #2 and Use one DTLS connection for all peers #14 and has since been improved, see: rawrtc/re@master...rawrtc:dtls-socketless
• Meson build system support: Not finished yet but already builds the library: rawrtc/re@master...rawrtc:meson
• libuv support: There have been a lot of people asking to use RAWRTC with libuv. There are two (here and here) highly experimental implementations of it and I expect this to be quite controversial. Nevertheless, adding external event loop support may be something feasible if carefully designed.

My plea is to reconsider the current conservative approach to changes for this project. I fear that if this is being continued it may eventually lead to a community effort to fork this project or people looking for alternatives.

Cheers
Lennart

[alfredh]

thanks for your input Lennart

currently the policy for the master branch is conservative. this is unlikely to change
any time soon.

we have clients who use this in their production systems, which require stability.
sorry about that.

do you have any suggestions for how to improve the situation ?

Alfred

[lgrahl]

Public API stability or implementation stability?

Public API stability: If this projects follows semantic versioning, and since it hasn't reached 1.0.0 yet, breaking the public API could happen with any release.

Implementation stability: I don't believe the three rejected additions listed above were a threat to that. All of them work fine in production and all tests pass. I could have written more tests - agree. But that's all from my perspective.

Regardless, if the above mentioned changes (all six) have no chance to land in master, then I don't see a way around a permanent fork. However, this fork could be maintained by you, similar to rew, if you are interested in maintaining a potentially less stable version of this library with more or different features. In that case, I would likely continue my contributions (at least get those merged which I've already mentioned).

[alfredh]

thanks for your input. please let us continue to discussion on re-devel,
or you can send me a private email.