On Thu, 13 Feb 2025 16:31:26 -0600, Justin Bertram <jbert...@apache.org> wrote:
| I would be happy to see folks step forward and embrace responsibility | for this code-base. If not, I'm also happy to declare this code-base | EOL. What I'm not happy to accept is this continued limbo where valid | problems never get fixed and there is no clear communication as to | why and what the future holds for the code-base. In my opinion this | situation is worse than either of the previous two. I suspect there are many more users of this code base than are willing to contribute to it. There are many reasons for this lack of community engagement, but lack of use is not one of them. Absence of evidence is not evidence of absence. The client library meets a fairly common need serviceably well. Its only obvious flaw, from a user perspective, is code obsolescence. C++ has moved on, but the code has not kept up. That is, what the code base, as is, _needs_ - as opposed to being a target of wish lists - is a cleanup for modern compilers. Today, this basically means the C++17 standard. (C++20 is another sea change, which may take a while to find widepread acceptance, so I wouldn't worry about it too much just yet.) Brand new code, whether for enhancement or replacement, is a strictly secondary consideration. Which is why I think looking for new primary contributors is asking for a little too much. How many C++ developers follow this @dev list? ASF rightly does not make it easy to join projects as well. It would be nice if the subproject had a "maintenance only" mode (say, anoounced prominently on its webpage), so that potential contributions would align better with expectations. For example, I think I'm in a position to offer a set of diffs in a JIRA to make the code base C++17 ready. All that would need is someone with privileges to commit the implied pull requests and test them. I don't think I'm ready to become a full-fledged project contributor, as the full scope of the responsibilities daunts me at present. The code base is fairly feature complete, and that's perhaps the best we should expect of it. Arjun --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org For additional commands, e-mail: dev-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
