This is a discussion about Gramps code development. It assumes some knowledge about the process: pull requests, merge status, lines-of-code, etc. Viewer discretion is advised. 
Developers using AI coding environments is changing the way that Gramps is being created. We see more quality contributions from more people. This is an analysis of that change.
First, let’s look at the number of accepted contributions over the last 4 releases (6.1 is on the verge of being released. And we’ll through in pending work for Gramps 6.2):
First, note that this is approximately a log scale along the horizontal axis. That is, time gets more compress as you move to the right. The charts look pretty uniform, but that is an artifact of the scale. In reality, the contributions get more spread out over time, but the number of counts is still the same over those longer and longer time periods.
Ok, what do we notice:
- v5.1 - probably a typical release—some merged within a few weeks, other over months
- v5.2 (the covid edition) – is a bit different with a very delayed spike after a year
- v6.0 - many last minute PRs (33) merged quickly
- v6.1 - few PRs, targeting FamilySearch integration and bug fixes
- v6.2 - these are all of the unmerged contributions waiting for approval or rejection
But this only a count of the collection of changes grouped into a bug fix, or feature. What is inside each of these? To get a better sense, let’s look at the number of lines of code that have been changed:
Here we can see some striking differences:
- v6.0 - a small number of lines of code, even though 6.0 changed some major infrastructure (JSON usage). 5k of those changes happened were merged quickly!
- v6.1 - more changes that v6.0 but focused and most merged in less than 3 months
- v6.2 - large amounts of code written in the last week, with many stragglers sitting for more than months
Our contribution policy for “enhancements” (eg, not bug fixes) is:
In reality many PRs don’t get merged until far later because:
I think we need to revisit this tendency: we gaining in large amounts of code changes (features and bug fixes) through the code base in part to AI contributions. Waiting months to merge them creates the situation that makes it hard on the developers to build on previous fixes and contributions.
I understand why we want to do this: it makes it easier to accumulate all of the bug fixes into the current release, and delays any merge conflicts until later. But it hurts development, and creates more work for all of the developers.
My recommendation is to merge much earlier in the process (after that 3 week embargo). That allows developers to test, and build on, these merges. This makes Gramps more tested, and speeds up development. This will help us align with the increased PRs and amount of code being changed.