I’m trying to understand our development flow. It seems like we have a backlog of around 40 PR enhancements that go back more than a year, since Gramps 6.0 was released. https://github.com/gramps-project/gramps/pulls?q=is%3Apr+is%3Aopen+draft%3Afalse Many developers have been creating PRs for the …

Here is a proposal, which is basically what we do, but being more responsive to PRs: Contributors make a PR, targeting: master if it is not just a bug fix latest maintenance branch if it is a bug fix Reviewers have at least 3 weeks to review it (I will personally have Claude review it too, so …

This has already been discussed before. We use our master branch as a develop branch. Bigger changes can use a geps branch if required so as not to break the master branch. I think that the problems that you describe could be solved just as well by merging PRs into the master branch on a more reg…

[image] Nick-Hall: I think that the problems that you describe could be solved just as well by merging PRs into the master branch on a more regular basis. Yes please! That would allow development and testing to continue without further waiting. And I think could have a large impact on major r…

I’ll also add that the next version of gramps-web could benefit from getting the current set of open PRs available as 6.0.8 or 6.1, whichever.

It ought to be acknowledged that a lot of this activity is thankless and on behalf of the community, I’d like to thank @Nick-Hall (gramps) and @GaryGriffin (addons-source) for doing the work. We should also celebrate that the time between patch releases has gone down, and the number of patch release…

[image] dsblank: If we relax the constraint that we don’t allow “enhancements” in a maintenance branch, we could proceed faster without having to wait almost 2 years to get those contributions out. I think that we should keep maintenance releases limited to bug fixes only, but we can increase…

I’d like to request a “polish” release to be scheduled 3 months after each major release. (delayed a bit if an emergency patch maintenance release was necessitated… since emergencies tend to absorb developer attention from less critical issues. And polish is, by definition, less critical.) Polish m…

I can get behind this proposal. To support item #4, can we be more intentional in tagging the Target Version in MantisBT? Developers who submit fixes can add a note to the defect suggesting which release it should be part of (following the current guidelines). Then we just visit the Mantis Roadmap …

This discussion has focused mostly on source control, releases and policy, but given the current state of the 6.0.7 AIO, the CI build (not just AIO, but other platforms as well) should be included in the discussion.

Instead of trying to rely on Claude (or any other AI) to do code reviews I’d recommend instead that you use the AI to create regression tests. Then setup the github ci jobs to run the tests on push. I think after waiting 22 years maybe we can start to knock a few things off this list… Test…

I recommend both: tell you what is wrong, and create tests to show that it is broken. Simply creating the test is not enough for many of us (including me!) to know where to start to fix the issue. I would love to start knocking things off lists at a faster pace. I’m not going to be here in another …

Development Process Recommendation: Adopt a develop Integration Branch

Development

Topic		Replies	Views
Gramps 6.1 Planning Development	37	623	April 18, 2026
Question about gramps on github Development	8	303	August 19, 2024
What is the process of merging pull requests in the add-ons project? Development	13	691	May 13, 2022
Workflows for publishing Addons and updates Development third-party-addon	20	223	November 16, 2024
Best way to submit patches Development policy	16	233	October 13, 2024

Development Process Recommendation: Adopt a develop Integration Branch

Related topics