Towards sustainable DBI maintenance
For 2022 and 2023, no concrete new features were planned. Instead, the focus has been on establishing a sustainable and steady pace of maintenance and responsiveness to user feedback. This blog post shows how we have been doing in this regard.
This is a continuation of the first blog post in this series.
This analysis is based on the GitHub issues opened in the r-dbi organization since development has moved to GitHub, for the following packages: DBI, DBItest, RMariaDB, RPostgres, RSQLite, dblog, RKazam. See https://github.com/r-dbi/issues/ for the source of the analysis.
In total, 2086 issues and pull requests were opened in the package repositories, of which 462 were opened in 2022 or later.
The bar chart shows the number of issues opened per year. In recent years, the vast majority of the issues were opened by contributors and non-members.
To analyze responsiveness, we consider the time it takes from opening an issue by a non-member to the first response by a member, and to closing the issue.
Responsiveness to issues has improved, the majority of issues are now responded to within a single day. Unfortunately, some issues still required more than two weeks until the first response. The situation is similar for pull requests: Some are reviewed within a few days, but others remain unreviewed for more than two weeks.
The time to close issues varies too. Many can be closed within a day or a week, but some issues remain open for months or even years. For PRs, it depends whether they were created by CI/CD or by a human. Autogenerated PRs tend to get merged or closed much faster, but the general pattern is similar to issues.
Moving forward
Unfortunately, I’m using RPostgres, RMariaDB and RSQLite only in a lab setting, not in production. The new docker repository is a step towards making it easier to test various combinations of database servers and client libraries. I hope that this will make it easier to experience what using these tools in production is like, perhaps in combination with increasing network latency and throttling bandwidth.
No lab setup can replace the experience of using these tools in production. To effectively maintain DBI and the backend packages, I rely on contributed issues and pull requests. I’m grateful for every issue opened, even if some may be not actionable for me. Luckily, for a substantial number of the issues, the first response actally comes from a contributor! If you are interested in helping out, consider watching one or several repositories in the r-dbi organization.
Thanks to Maëlle Salmon for her help with the blog post.