The vote passes, thanks all for your support :)

Ronny, would you be able to tell NH that CouchDB approved the plans? Thank you!

Best
Jan
—
> On 3. Oct 2025, at 12:56, Jan Lehnardt <[email protected]> wrote:
> 
> 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
> —


Reply via email to