This month has seen a record number of contributions to Gramps! First, let’s take a look at the data. Here is a chart of all contributions (called “pull requests”) that have been submitted to our source code repository (the chart ignores draft and closed contributions):
The chart starts in 2015 as that is when we started using github.com. (We could do a similar estimate before 2015 by looking at the old files. Let me know if you’d like to see that.) Another way to see the original system being created is to watch this 8 minute video I made back in 2010. It shows development between 2003 and 2010.
Anyway, I wanted to point to that increasing bar height on the right-hand side of the chart above. Not only do we have an increasing number of contributions, but these are high-quality bug fixes and enhancements. And we’re not done with the month!
Why now? Well, for a couple of reasons: we have some amazing new contributors, and many of us have been using AI to make these bug fixes and enhancements. Some of these are small fixes, but some of them are larger and are really making Gramps a much solid code base than ever before.
Gramps 6.1 will have some fixes that you have been wanting for a long time. Not to mention many new and enhanced 3rd-party addons! And Gramps 6.2 may have the enhancements you have been asking for.
We all hope that we don’t end up in the situation that happened between 2020 and 2024… you can see there were many many contributions made, but 4 years went without a release.
The lack of a release between 2020 and 2024 was largely due to covid. Many of us had other priorities at the time.
There has been a sudden spike recently. I’ll start reviewing some more PRs. I work in batches so you will see more months with increases rather then decreases.
The improvement of coding agents since end of last year has been breathtaking and it has increased my productivity by an insane amount, and producing code that is higher quality than before (because, unlike Gramps desktop, I used to often merge my own PRs without anyone reviewing them - now I get reviewed by a fleet of agents).
I also see a spike in contributions (this is partly due to the spiking popularity of Gramps Web, but certainly spurred by agents as well). Some of it is AI slop, but surprisingly little. I did feel the need to adapt the contributing guidelines - I definitely see lots of PRs with too little prior discussion.
Overall, I think this is a great development of the Gramps project. Kudos to all devs!
I’m glad I could be helpful - it’s a fantastic way to give back to everyone having used so much OS over the years and take care of something truely personal.
Little nitpick on the contributing link David - it points to a commit and not the full file.
What is your evaluation about the quality of these AI-assisted fixes?
I am the chief manager on a FOSS project. Recently a user met a serious problem with it and asked some AI to solve his issue. This particular case was fixed but
it made the structure of the impacted modules more complex
the AI over-simplified a side definition causing failures in very common cases
the AI did not understand the generic aspect of the code, retaining only the particular case (and creating havoc in other contexts normally handled by the generic code)
After analysing what the AI did, I could find the primal cause of the particular problem and fix it “elegantly” (a 2-line patch) by modifying the parameters of the generic code which is left unchanged (instead of introducing what looks like obfuscation).
After analysing what the AI did, I could find the primal cause of the particular problem and fix it “elegantly” (a 2-line patch) by modifying the parameters of the generic code which is left unchanged (instead of introducing what looks like obfuscation).
This is a heated discussion in many corners. I’ve been using Claude Code for a couple of weeks and there are definitely pitfalls you need to be mindful of. Here a list of my experience with AI models and how you can make it work:
The AI model matters - I’ve worked with Gemini, Anthropic, locally installed models using Llama and right now Claude Code beats pretty much any of the other ones in development hands-down. That’s because it’s one of those use cases they have been specifically training the model for. The more generic the model (e.g. Gemini Chat), the less usefull they are for specific cases where up to date knowledge is important. Gemini had the unfortuante habit of providing out of date information when the Internet documentation was still full of the outdated stuff. Im happy to point me to something even better.
You need to build a proper test harness. Even Claude Code had a habit of just reading the code and concluding stuff from that. You need a runtime test harness that helps the AI verify what it has done. You also need to ensure that Claude actually keeps to the rule “first verify”. An “unprompted” AI will have a tendency to just do static code analysis and conclude from that. You can take care of it by storing these things in memory and you end up asking the AI to build tests, tests, tests and choosing technologies that let the AI interface with the test harness.
You need to document the unspoken conventions. Many project specific conventions are distributed over the body of documents and these need to be distilled and provided to the AI. Some of that is committed to the Agents Markdown or similar and some of it needs to be committed to memory. You also need to ensure the AI reads those things at the start of the session to avoid it from doing silly mistakes over, over and over. And know when to start a new session.
You need to be specific in your prompt. Depending on the chunk of implementation you do, you need to have a “planning session” with your AI, walking it through design decisions and what is important. You also need to understand the implications of design decisions, especially if the chunk of design is big enough, as AI will just barrel ahead and you end up with spaghetti code.
Invest in “clean up” sessions and retrospectives. Every time you have a “brain fart solution” from the AI (doesn’t solve the problem, too complicated, etc.) you need to review what went wrong with the AI. They will review what happened and suggest improvements but only if you prompt. And the commit that to memory of course. A corollary is to sometimes take a step back and reflect on what has been built - ask the AI to identify improvement potential, etc. Make sure to use a fresh session or even a different AI model and have them “duke it out”. With AI it is easier to “first build” and then refactor, especially if your test harness is in place.
In many instances where I’ve discussed the use of AI in development people have reported of anecdotal “I tried it and it was a mess” and I fully understand why they react that way. You need to invest some time and effort to make it useful, but once it’s in place and running there’s just no comparison.
Firefox reported similar experience when they talked about the Mythos Model. They needed to setup the test harness and finely adjust it, but afterwards it really generated highly accurate zero day bugs.
I found Anthropic Claude to return Gramps modules that tended to work earlier in the cycle. (Perplexity took several more passes before a wish-coded module stopped erroring-out and tended to recreate the same problem or attempt the same failing fix. ChatGPT was only rarely reaching the finish line.. getting there required a heavy hand on the reins and brutal use of the spurs.)
But it was interesting having a different AI assess Claude’s code and suggest streamlining that would not lose functionality.
That is hard to answer because the development of any code with an AI coding environment is a process, a conversation between the AI and the developer. First, as @eduralph mentioned, the initial prompt has to be specific not only in what you want, but often giving hints about how to implement it are needed.
And then, it usually takes corrections and further queries to drive it to a final solution. Follow-up questions are often critical, like: What is the performance impact of these changes?
More complicated solutions often need to be done in phases, otherwise the AI would try to solve a problem all in one step leading to a mess of a solution.
So to answer your question: it often depends on the skills of the human.
Last month was indeed a record-breaking month for features and bug fixes submitted to Gramps github repository. And this month looks like it will break that record!
But that refers to just the count of contributions, not the quality of fixes and enhancements. Many of these contributions have fixed bugs that have been around for a long time, and some add features we have only been able to wish for before. AI has certainly changed the development for many developers. And some are still contributing the old fashioned way
How many months of record-breaking contributions before we realize that we might want to adapt the release cycle and process?
We have had a great release cadence through 6.0.8. 6.1-beta has thrown that off and while I understand the resourcing problem, it points to us finding a way to make a release a “non-event” so that we can continue to release fixes for important bugs while we focus on the next big release. I appreciate @Nick-Hall improving the documentation of the release process to get us closer.
@dsblank What did you have in mind as far as adapting the release cycle and process?
If we could automate (or semi-automate) the packaging of a release, then we can release whenever we want. If things weren’t translated, users could add their translated texts, and it would appear very quickly in the next release.
I work for a company that has at least one release every day. All of that is automated.
Would love to see a gramps-nightly build that users could very easily try what was just merged. If we could speed up the merges that would be a game changer.
Version 6.1 has involved a collaboration between Gramps and FamilySearch. This is a first time for us, but I believe that it is big step forward. The FamilySearch integration is probably the most significant enhancement in the time that I have been involved with Gramps.
It is amazing that Gramps can still excite developers! I know I have felt that way…many times! The transition to SQLite; the removal of blobs and use of JSON; the development of the addon system; the creation of gramplets; development of gramps api and web; the development of filters, proxies, and geographic mapping. And lots of little things!
Your excitment does explain why we got a release out so quickly. Iit can be frustrating that it can take so long to get something that each developer feels is a very significant enhancement. I too look forward to the FamilySearch integration. And I am also excited about Gramps 6.2… or what I hope will be in it. So many PRs!
I have a recent sample in mind, making some ‘non-academic’ contributions and bug fixes on gramps-project in the past.
Last months, after intentionally creating errors in thread management to see how Gramps reacts to, I came to the conclusion that with this exponential growth and the quality of the contributions for these recents PR(s), I will no more able to keep my foolish (unsafe) way for testing gramps reactions, as I will no more able to test with the most recents versions (devel state). AI may help, but my oldschool ‘step-by-step’ way for testing often disturbes the coding model. So, for more flexibility, my prompts only asked AI on an help for coding errors (like I did before), then making some slow clean-up steps. While the error step isn’t fixed, the AI will no more try to go further (or too far), and I feel like I still keep the control… That’s my current guard and workflow, but as I learned coding by looking at gramps code, this is just an other way for contributing with my limits and ressources. Standard coding and devel environment might be a best and safe way.
eg., there is (or not) a possible issue with an empty date set and the span quality on Date object. I looked at unit tests but was not able to generate a quick and proper (quality) PR.
Without docker or any virtualization stuff, I had to test it on gramps-6.1 beta release, apply some patches from PR, look at commit logs and get back my empty span date issue (was an external script) without current workaround, to see if this could be fixed on gramps 6.1 with some PR (bugs fix). Sure, could also try to patch my current active branch too (backport), but this does not make sense for a devel contibution or any bug report.
So, git and automatic control tools (or unit tests) were for me the start of the pre-AI period time! Sure, 100% human tests means to understand the complete code (full), which is currently no more possible on a so big ecosystem. Last contributions and recent(s) PR(s) look so complex. I just wonder how AI reads (or stores in memory) all workarounds still remain(ing) on some parts of gramps’ code? I guess that comments on code should be checked or reviewed for AI (take care for the quality of them, like a prompt)?
ps: sorry, I wasn’t able to properly use the spell (grammar) checker with my locale and the AI helper provided with gramps.discourse
Update: maybe I was a little bit lazy with the date span support on my custom Gramps XML template on the external script… Anyway, the possible import problem with empty date values seems to be covered on:
@dsblank Not having been involved in a release, I would like to understand the current process and where the sticky parts are. Let’s continue the discussion of automating the release process separately/offline. I’m in touch with @Nick-Hall as well.
And Nick, I certainly appreciate the effort that has gone into the feature set for 6.1. I can see how this adds value and has potential to bring new users to Gramps. Thanks!
have the enhancements you have been asking for.
