Hey all, I’d like to call a vote by lazy consensus on the tasks Neighbourhoodie agreed to tackle under STA sponsorship (see previous vote[1] for full list of possible work items).
[1]: https://lists.apache.org/thread/68oovrb2d3gg668gpzqfl222nzqccg6b This vote closes Monday, 2025-10-06, 11:00 UTC. — As before, due to a conflict of interest, I am excusing myself from this vote. — Milestone 1. Parallelising eunit tests Objective: As an established and long-running project, CouchDB's test suite has grown extensive and requires significant time to complete. While it is expected for extensive test coverage to result in longer runtimes, there are performance improvements that can be achieved by modifying the existing configuration. These optimizations will shorten CI run times, which will reduce computing resource consumption, decrease the waiting time developers spend on its completion, and cut the time needed to get critical security fixes into releases. Additionally, this also accelerates the overall development process, since developers rely on the test suite to validate that changes to the source code do not introduce errors. One of the test suites that CouchDB has is eunit, tests written in Erlang. All of these eunit tests are executed sequentially. With the implementation of parallelism it could potentially improve several seconds of execution time. Deliverable: One or several PRs with modifications to the test source and configuration to parallelise the run of eunit tests Technical Details: - Familiarise with the test suites - Investigate how to safely achieve parallelisation, and parallelise the tests as much as possible, aiming to use the available environment’s resources, that result in performance gains - If possible, fix tests that cannot be reliably run in parallel with others, or exclude them from parallel execution - Document the current state and measure the improvements - Opt-out option to disable parallelism (for example, for debugging purposes) Milestone 2. Run test suites in parallel Objective: As an established and long-running project, CouchDB's test suite has grown extensive and requires significant time to complete. While it is expected for extensive test coverage to result in longer runtimes, there are performance improvements that can be achieved by modifying the existing configuration. These optimizations will shorten CI run times, which will reduce computing resource consumption, decrease the waiting time developers spend on its completion, and cut the time needed to get critical security fixes into releases. Additionally, this also accelerates the overall development process, since developers rely on the test suite to validate that changes to the source code do not introduce errors. CouchDB has multiple test suites, including eunit, exunit and Python. The execution of all of them takes up to 10-20 minutes on modern hardware. In CI with a wide matrix, this can lead to PR and main branch CI checks that run for hours. The implementation of parallelism could potentially improve execution time substantially. Deliverable: One or several PRs with modifications to the configuration to parallelize the run of the test suites Technical Details: - Familiarise with the suites - Investigate how to safely achieve parallelisation, and parallelise the test suites as much as possible, aiming to use the available environment’s resources, that result in performance gains - Document the current state and measure the improvements - Opt-out option to disable parallelism (for example, for debugging purposes) Milestone 3. Convert Python test suite to eunit or exunit Objective: A sub-component of CouchDB (Mango) has historically been tested with a Python-based test suite. It is an outlier among all other testing which is either done in Erlang or Elixir, both of which are Erlang-ecosystem-native options, while Python is not. Both writing new tests for this component as well as maintaining this test suite requires a completely different set of skills than the rest of the testing environment. CouchDB testing would be greatly improved by converting these Python-based tests into the existing eunit or exunit test suites. Converting this suite away from Python will decrease CouchDB’s technical debt, simplify the codebase’s configuration, reduce its size, decrease the time the contributors spend setting the environment, and lessen the effort the maintainers spend maintaining and extending the test suite. Deliverable: One or several PRs with the conversion Technical Details: - Familiarise with the python test suite - Convert the fixtures and tests in an orderly manner - Deprecate the converted tests - Note that we might not be able to convert the whole test suite, but we will migrate as much as possible given the allocated time. If that’s the case, document how to continue the conversion for other contributors to continue the task Milestone 4. Improve Operational Security Objective: One of the security mechanisms CouchDB has is per-database document update validations (VDU), where users can establish requirements to satisfy before updating documents. The current implementation of this mechanism is written in JavaScript, which comes with many limitations. As a consequence, the CouchDB team recommends not using it even on medium-scale setups, as it is so time costly that the disadvantages outweigh the benefits. This presents a substantial wart in the CouchDB security line-up and the project would like to introduce a new, declaratively provided way of achieving most of the same things that VDUs are being used for. Since 2018 there have been efforts to design a new system that could solve this problem, unsuccessfully. In addition, there are two competing design approaches for the schema validation aspect of VDUs. Providing a design discussion of both options will help CouchDB move forward in its implementation, which will increase the overall security of the project and their users. Deliverable: A report with the new design implementation of a declarative way to achieve most of the use-cases that the current system allows, without any of the runtime penalties. This will include separate designs for schema validation and the description of authorization rules. Technical Details: -Familiarise with the current JavaScript implementation -Read the original proposal issue on the topic -Investigate and write a report with the proposed design implementation Best Jan —
