There’s a mailing list thread going on, discussing some proposals for modifications and POCO contributing process. This discussion occasionally turns heated and there is a lot of misinterpretation and misunderstanding going on, which has prompted me to summarize the contributing issues/concerns and post them in one place as a clarification for all the folks who are currently contributing or are considering to do it in the future.
Before I say anything else, let me emphasize that we always solicit contributions. We value all the contributions and give any idea due consideration within the limits of our ability. Like any other worthy endeavor, bringing a contribution to the release-grade code is hard work – there are no shortcuts to any place worth going. The hardest part is sometimes directly related to the complicated nature of the issue at hand. But more often, the hardest part is to take care of the details accompanying the process of integrating the contribution into the framework:
- Study the contribution code (and architecture, where applicable) to verify it indeed makes sense, from all the relevant standpoints, to integrate it.
- Verify the contributed code complies with the coding style guide (which reminds me that it would be nice to have automatic checker). If not, edit until it does (this can be VERY time consuming)
- Incorporate the code into POCO source files and/or directory structure.
- Modify the build system if necessary.
- Verify the code compiles on supported platforms
- Verify the tests pass on supported platforms/compilers
The above list is abstract. Amount of details and time spent on each item can vary greatly. At any rate, it is a time-consuming process. The more of the above concerns are addressed by the contributor prior to submitting the code, the less work we have to do. Ideally, the contributor addresses all of the above concerns, is a committer himself, commits the code and we have nothing to do. That’s a very rare thing to find and it is, understandably, never the case with new contributors – everyone needs some adjustment time to get the proper “feel” of the environment.
Now, a bit about the types of contributions. Here’s the list:
- Reporting POCO usage
- Opining on POCO
- Submitting Bug Reports
- Submitting Patches
- Submitting Feature Requests
- Writing a tutorial, how-to, or a technote
- Contributing classes/implementations (e.g. SMTP logging channel)
- Contributing modules (e.g. ICMP module, see ICMP*)
- Contributing libraries (e.g. MySQL connector)
- Taking ownership of a cross-cutting concern (e.g. build system for a platform/compiler, e.e.g. MinGW build)
- Submitting various ideas and concepts (see sandbox, e.g. C10K, atomic operations, etc.)
- Taking ownership of a library in trunk/sandbox (e.g. Data/Servlet)
- Modifying essential portions of the framework
- Working on alternative POCO versions/directions
OK, now, the last two items are something we do not currently have an example for, so let me spend some time explaining it. We are very willing to grant write access to someone who wants to experiment with alternative POCO directions.
Based on recent requests from some users, here are few examples:
- replacing use of mutexes with atomic operations where appropriate
- replacing threads with coroutines where apropriate
- experimenting with asynchronous IO
This is by no means a complete list. If you want to play and experiment, by all means let us know. We will give you Subversion write access and you can go play in the sandbox. Should you desire it, you can even get your own branch in the repository containing a copy of the current POCO trunk.
What is the purpose of such thing? Well, you may come up with something really cool and we may decide to backport it to mainstream POCO. There is the opposite possibility as well – you may be enamored with your work, but the POCO community may not be so thrilled, so you decide to pack your bags and launch a project of your own. Not a problem, as long as you respect the license (i.e. display it properly to give due credit to original authors), the project name is not POCO and it does not live in Poco namespace. We currently have no legal means to prevent you from doing it, but it would be rather ridiculous (and confusing) to have multiple C++ frameworks named POCO and it would only serve to hurt both parties.